Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Reactive Monolith – How to Move from CRUD to Event Sourcing

wix.engineering

Post reply on HN
Print view View original

51–60 of 112 posts

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#51

Post by square_usual »

blowski wrote: post #34
holoduke wrote: post #29

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple of months back, a QA review reported a bug - the log system didn’t work. Turns out it’s never worked. Nobody has ever done a rollback either.

Oh yeah, I've run into similar situations so many times. A critical piece of functionality was overnegineered and shipped, only months later did we find out that it never worked, and nobody found out because nobody used it.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#52

Post by jordanbeiber »

the_duke wrote: post #17
0xFACEFEED wrote: post #4

I feel bad for anyone who got sucked into event sourcing for general purpose applications. Like... I'm burning a candle for you right now. The event stream stuff makes sense in some specialized use cases (LMAX?) but for general purpose stuff? Oof, no. EDIT: Also, don't hate me folks, but any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite…

Event sourcing could be a great architecture for general purpose applications - if we had good frameworks and specialized event stores built for this purpose. Some features that would be needed: * Automatic , schema based event and aggregate versioning * A combined event and aggregate data store with ACID guarantees, schema validation and indexes * event migrations (so you don't have to carry around old event version…

Look at Zeebe[1] for example.

If you declare the business process you want to support - either in code or in BPMN, you're automatically mapping out the events that are relevant to the business.

Having a system that takes care of executing this, and tying the pieces of this workflow together is one example where ES can shine IMHO.

[1]https://docs.camunda.io/docs/product-manuals/zeebe/technical...

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#53

Post by goostavos »

0xFACEFEED wrote: post #4

I feel bad for anyone who got sucked into event sourcing for general purpose applications. Like... I'm burning a candle for you right now. The event stream stuff makes sense in some specialized use cases (LMAX?) but for general purpose stuff? Oof, no. EDIT: Also, don't hate me folks, but any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite…

Count me in the long line of suckers :(

Probably one of the largest technical blunders of my career (or at least the largest so far!) was pulling a team down into ES hell on a greenfield project.

Turns out, growing an event sourced application is fantastically hard[0]. Ours eventually became a twisted opaque mess which was terrifying to modify due to (a) the sheer volume of code it took to do so, and (b) eventually losing control over who read which events and where as the team grew.

[0] https://chriskiehl.com/article/event-sourcing-is-hard

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#54

Post by cuddlecake »

runeks wrote: post #44
Flankk wrote: post #33

Earlier quoted context omitted.

It's not practical. That's why all the arguments for it involve overstating and hyperbole. The results speak for themselves. It's shit.

The question is whether it’s not practical because it hasn’t received the three decades of engineering that relational databases have, or because it’s broken in theory.

I think, for one given moment in time, Event Sourcing is the hottest thing you can have. Evolution is where the trouble's brewing. You add a column to a table with maybe a default value, all is good. You add a property to an event's payload, you suddenly have to deal with versioning.

Event Sourcing with its current ecosystem and frameworks mainly add technical complexity with very little added clarity of business.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#55

Post by throwbabyaway »

he0001 wrote: post #49

I had this team of consultants which sole purpose was to introduce an ES system, it was my predecessor that had decided this. The consultants were “experts” on building this kind of system. Very long story short, it failed miserably with a completely broke system which was hard to test, failed pretty much all use cases and completely blew budget. According to the team there were many reasons why the project failed, o…

My wife was diagnosed with PCOS (poly-cystic ovary syndrome) and we learned that it reduced her chances to get pregnant.

Few weeks later we were sitting against this famous reproductive endocrinologist who were explaining us our options:

- Yeah, going to a fertility clinic is of course an option. However, you should at first perhaps consider a more traditional approach instead.

- What is the traditional approach, some medication?

- People seem to have forgotten how to have sex these days.

However embarrassed we were at that time (BTW he then laughed and saved us from the awkwardness), trying the obvious, easy solution and taking care of problems as they come became a conscious thing afterwards. I love over-engineering, but asking myself and the other stakeholders "what are we actually trying to accomplish here" is the most engineer-like thing I do nowadays.

I'm not suggesting just winging it all the time, but looking for the easiest solution first, not last. That's all.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#56

Post by vegai_ »

Flankk wrote: post #33
holoduke wrote: post #29

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

It's not practical. That's why all the arguments for it involve overstating and hyperbole. The results speak for themselves. It's shit.

Two examples of systems that use a variant of event sourcing:

- relational database systems (their journals and async replication in particular)

- git

Perhaps not so shit. Perhaps a bit practical. It's just a bad fit for some problems and architectologists like to say it's good for everything for obvious reasons.

And it's should be pretty obvious that architecture doesn't matter at all if it's implemented poorly.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#57

Post by shironandon »

blowski wrote: post #34
holoduke wrote: post #29

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple of months back, a QA review reported a bug - the log system didn’t work. Turns out it’s never worked. Nobody has ever done a rollback either.

Was working on a client's stack and this one critical piece using ES (written by "experts" who had since left the company) was throwing an error every week at 2 AM triggering alerts and chaos.

After investigation I found nobody understood what it was doing or why. I thereby found the safest approach was to delete the ES implementation.

After that everything worked and everyone was happy.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#58

Post by dm3 »

blowski wrote: post #34
holoduke wrote: post #29

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple of months back, a QA review reported a bug - the log system didn’t work. Turns out it’s never worked. Nobody has ever done a rollback either.

I understand this thread is about dumping on ES... However, I must notice in your case it was an audit log. An ES system wouldn't work at all without access to events.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#59

Post by holoduke »

lmm wrote: post #45
holoduke wrote: post #29

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

Prevent lost writes from when two people read-modify-write at the same time. Be able to answer questions like "how did this end up like this" or "what happened to the change I made on xx/yy". Easier sharding, better performance, and avoiding deadlocks, because you're not worrying about database-level transactions any more. Much easier data migrations that you can do in a gradual, rollbackable way. Clear data provenan…

Could you elaborate how you solve transaction, double writes , deadlocks. I mean the consumers do still process messages in parallel right? Or do you force a serial pipeline to avoid handling messages at the same time? I thought that EV is more about creating entire separate entities/codebase which have zero dependencies.
Post reply on HN