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

101–110 of 112 posts

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

#101

Post by marcosdumay »

rapnie wrote: post #82

It is striking that this thread attracts so much negative commentary, while a similar thread 49 days ago is the exact opposite. It may be interesting to have a look and compare: https://news.ycombinator.com/item?id=28140598

Well, this one is about moving from CRUD, that is the most mainstream paradigm on software development into what is solution to a very niche problem, while the other is just about the solution.

This article isn't really pushing people into an overengineered and disastrous situation only because it doesn't say everybody should follow it. But it's a really bad article for everybody to follow and people are reacting like if it was recommended to them.

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

#102

Post by nickkell »

fullstackchris wrote: post #97
classabove wrote: post #47

Earlier quoted context omitted.

this is absolutely terrifying

not if nobody uses it ¯\_(ツ)_/¯

It's similar to database backups - hopefully you'll never need it, but at some point you might. At that point you'd hope your data was intact

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

#103

Post by deepanchor »

kitd wrote: post #85
zaptheimpaler wrote: post #67

I used to be really excited about event sourcing but yeah, its usually just over-engineering. It appeals to the nerd in me because its a powerful & clean model - events are immutable, your entire database can theoretically be reconstructed at any point in time by just replaying an event log up to time X. In the ideal form its sort of the highest fidelity version of data storage, throwing nothing away, supporting all…

ES is the C in CQRS though. If you're using it for the Q too, then it's no wonder you'll quickly get in a bad way. It's specifically not designed for that.

As I understand it, ES and CQRS are somewhat orthogonal concepts (although they are indeed often used together). It's perfectly legitimate to implement CQRS without using event sourcing at all.

The only thing CQRS dictates is that a system's read models are separate from its write models.

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

#104

Post by gunnarmorling »

nivertech wrote: post #72
_3u10 wrote: post #3

And then you realize that the CRUD db you moved away from operates on event sourcing (WAL) anyway. And thus you’re just doing inner platform effect.

Correct, and many applications are using WAL via CDC (Change Data Capture) to gain some of the benefits of the CQRS/ES. The problem is that the CRUD is only recording "What" change/mutation was done, but not "Why" by "Whom", and "When" it was done. With tailing WAL / CDC you can also capture the "When". This can be partially mitigated by adding audit fields like: Why (reason for change): created_bc ("because") / crea…

If you use log-based CDC, you typically don't need those timestamps, the WAL will contain and expose that information. It's a different story for more semantical properties like a "user" or a "use case" associated to some change. One way for capturing these intents is to log that information transaction-scoped in a separate table and then use downstream stream-processing to enrich actual change events (which contain the TX id themselves) with that metadata. I've blogged about one way for implementing this using Debezium and Kafka Streams a while ago: https://debezium.io/blog/2019/10/01/audit-logs-with-change-d....

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

#105

Post by _3u10 »

kortex wrote: post #91
_3u10 wrote: post #88

Earlier quoted context omitted.

Yup a few fields gets you a long way, though I would recommend an audit log updated by triggers, rather than audit fields. For example on my CRUD rails app, we use audit triggers in combination with setting a postgres local config variable with the username, the audit triggers pull the user info from the variables and record them into the DB. With a little more work I could probably also pull a backtrace of what line…

What kind of technology/data model do you use for the audit log? A timeseries db, just another table, or something else?

Another table in a different schema. Roughly this https://wiki.postgresql.org/wiki/Audit_trigger_91plus

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

#106

Post by kitd »

deepanchor wrote: post #103
kitd wrote: post #85

Earlier quoted context omitted.

ES is the C in CQRS though. If you're using it for the Q too, then it's no wonder you'll quickly get in a bad way. It's specifically not designed for that.

As I understand it, ES and CQRS are somewhat orthogonal concepts (although they are indeed often used together). It's perfectly legitimate to implement CQRS without using event sourcing at all. The only thing CQRS dictates is that a system's read models are separate from its write models.

That's very true, but the benefits of ES come on the write side of the equation. Expecting it to solve read-side problems will inevitably lead to disappointment.

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

#107

Post by zenron »

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.

ES is practical if your use case supports it. I think you only need to look at Citibank's success post 2008 banking crisis to see the successes they've had as a company. When their developers were touring the No Fluff Just Stuff events in 2015-2016 showing their work and how much they were giving back to the projects they were using really puts a stick in your wheel.

Financial systems can really take advantage of it. Your post is hyperbole.

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

#108

Post by blowski »

nickkell wrote: post #102
fullstackchris wrote: post #97

Earlier quoted context omitted.

not if nobody uses it ¯\_(ツ)_/¯

It's similar to database backups - hopefully you'll never need it, but at some point you might. At that point you'd hope your data was intact

The cost of doing a database backup is usually much lower than the cost of doing event sourcing.

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

#109

Post by antod »

codeflo wrote: post #65
vegai_ wrote: post #56

Earlier quoted context omitted.

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.

We have to be very precise here I think. Git doesn't really store file changes as events, rather, it's a long chain of state snapshots, in something like a persistent data structure. Sure, the history is all there, but so is the current state in its most efficient form. DB transaction logs might be considered event sourcing by some definition, but their use is very different. It's purely a technical trick. As a conse…

yeah, describing git as a stream of change events sounds more like the way svn or mercurial worked than git.
Post reply on HN