News for hackers. Stuff that matters.

A comment on Mistakes we made adopting event sourcing and how we recovered. Parent comment

Re:Mistakes we made adopting event sourcing and how we recov... by mycall on Monday July 01, 2019 @10:08PM (#20331530)
> The event stream is exactly the same as a commit log in a regular DB

This assumes the content in the commit log are client events, not CRUD on table data actions (events are higher order).

> the whole event history is not useful and consumes huge amounts of space

When a greenfield project is starting up, data is gold. 8TB drives are $242. Create a data lake from the start.

[ Parent | on HN ]
Re:Mistakes we made adopting event sourcing and how we recov... by nullwasamistake on Wednesday July 03, 2019 @02:17AM (#20342051)
I disagree. The events tend to relate directly to what would be regular database tables in my experience.

And data is the new oil is definitely a businessweek cargo cult. None of the event data was of any use on the projects I worked on. We were under mandate to find something to do with it and still couldn't. The closest useful thing was allowing undo and replaying past events but we already had that on Postgres with hibernate auditing on interesting tables (money related stuff)

[ Parent | on HN ]