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

61–70 of 112 posts

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

#61

Post by swyx »

jordanbeiber wrote: post #43
dmitryminkovsky wrote: post #19

Earlier quoted context omitted.

I second this wholeheartedly because this happened to me. I'm the kind of person who learns by my making my own mistakes (as opposed to learning from others', which is what smart people do)—and boy, did I learn a lot from the mistake of trying to build a general purpose application with event sourcing. Theoretically, event sourcing is the way all applications should be built. I was first taken by this methodology by…

I believe ES has it’s uses in discreet systems doing their thing for you. For me ES makes perfect sense in systems handing a workflow for you. Products like Zeebe[1] and Ubers Temporal[2] comes to mind. These systems basically becomes your business transaction log and as such ES is just a great fit. (I have no idea whether ES is used in temporal though… never looked at the code) [1] https://github.com/camunda-cloud/z…

hi! I work at Temporal. ftr our founders left Uber 2 years ago and Temporal is an independent startup (that is very much hiring) now.

Short answer is yes, we do, but it's abstracted away so you get the benefits (complete observability, retry/resume from failure) without the downsides (handwriting event sourcing logic and storage).

Long answer... it depends what your definition of event sourcing is. We shared some of our internal debate here: https://news.ycombinator.com/item?id=28149159

Event sourcing is an impt implementation detail for us, but it is not something we push onto our users. Still they benefit from it anyway. very much agree with your statement. happy to take followup qtns :)

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

#62

Post by mistahenry »

wrwatson wrote: post #21
nuclearnice1 wrote: post #6

Earlier quoted context omitted.

What makes event sourcing poor for general purpose stuff?

The first rule of data modelling is that you should model only what you care about. A good model allows you to store and retrieve what you need to meet your requirements. Maybe you care about all the events that have ever happened on your incredible journey to reach a list of the customers you have today. Or maybe it would be sufficient to have been mutating a customers table all along. If that is sufficient, then it…

This is why I always like to have a `status_history` or `audit` table. You don't have to have event sourcing to still want a trail of who changed what in the system when.

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

#63

Post by tlarkworthy »

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

not sure about event sourcing, but replicating your state immutably on write can save your bacon if there is a bug. I try to skip the D and make the U fork in CRUD for systems where the data is very valuable.

classic event sourcing require playing your events in order to calculate state. I think that's a complexity. Just do normal state computation but write it into a new timestamped row

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

#64

Post by JamesBarney »

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

Here's why I used event sourcing.

We were modeling well dynamics. And to calculate interesting properties of the well we needed sensor data, the previous state of the well, and a model of the well built by a petroleum engineer.

Unfortunately the model of the well wasn't always up to date (pump was replaced, etc..), so we needed to be able to replay all of the sensor data into the well when a model was retroactively changed. Event sourcing was such an easy pick because our events were very simple (15 fields of data) and our replay requirement was a showstopper.

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

#65

Post by codeflo »

vegai_ wrote: post #56
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.

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 consequence, logs are truncated as often as possible/reasonable, and you never rerun the transaction log from time zero. Very different from the event sourcing idea to keep events as long as possible.

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

#66

Post by beaker52 »

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…

I'm working with a team that's in the process of decomissioning a previous teams attempt at ES. Even the new team wanted to do ES, whilst staring at the remains of the previous attempt. Luckily they haven't.

Usually arguments go "we need an audit log so ES is a natural fit and we'll be able to iterate quicker because we can just re-project when we get things wrong, oh and testing is really straightforward too because we can just...".

You can have an audit log without ES. You're also going to hate versioning events. And navigating your tangled nest of events that you accidentally accumulated in the name of agile isn't the nirvana you were hoping for.

I believe it's better to have a system that responds to the requirements of here and now, leaving history behind, learning from mistakes going forward and accepting that yesterday is done.

In my experience, in growing software systems, you're more likely to have not to have even had the data/event at all, than to not have misappreciated what you already had. So event logs feel more like a bunch of baggage ready to trip teams up than a wealth of value.

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

#67

Post by zaptheimpaler »

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 ways of querying as materialized views or dependent DBs built on the stream. Its beautiful.

But also we live in reality. DBs use checkpoints because storing/replaying an event log from time 0 would take ungodly amounts of space and time. You deleted or resized a column to save some space? Lol no, the event log lives forever. You wanted to use SQL, a battle tested language to query your data? Lol no, the database is "inside out" so tough luck buddy, you're building the database now. Sure you might have to rebuild compaction, joins, query languages, concurrency control and the other 100 things a DB gives you, but on the plus side that one audit log that you could have built with some glue and a few INSERT triggers in Postgres is now an elegant map/reduce on your 100TB dataset! Yay!

Mad props to the consultants though my man wanted a car you sold him a car factory. Take that money to the bank, get a Lamborghini, travel the world drinking and talking shit at conferences fuck yeah. Fuels getting expensive, throw in some machine learning sauce, get a yacht all I do is win baby.

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

#68

Post by _3u10 »

vegai_ wrote: post #56
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.

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.

Here's the key, all the systems in which event sourcing works have clear immutable definitions of what an event does / means.

eg. Git ALWAYS applies a commit in a consistent way (and where it doesn't it's a disaster)

eg. If you modify the transaction replay code from one version to the next of a DB, it creates a mess. (and why many databases won't replay transactions from previous versions, or even boot at all, see Postgres)

The problem with event sourcing is that the same bad practices that came from the CRUD system are recreated using events, which makes the system inherently worse because now the state of your system is unstable, instead of just the manner in which you got to the current state.

Imagine if everytime your rebooted your Postgresql cluster and it replayed Postgres 7 transaction logs, even though your running on Postgres 13, and generated an objectively different state, except, now your using CI and every commit from every developer will boot your system into a different state. Also, your database now takes 2 months to start as every transaction gets replayed.

Take rails db migrations for example, the best practice is, every 6 months or so, to just dump the schema from production, create one large initial "migration" and add migrations from there, because eventually they become desynced, and you can't cleanly replay your migrations into a schema that mirrors prod.

If you are extremely careful, and follow a bunch of best practices you can, but in the general case it costs less to just dump schemas.

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

#69

Post by y4mi »

JamesBarney wrote: post #64
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

Here's why I used event sourcing. We were modeling well dynamics. And to calculate interesting properties of the well we needed sensor data, the previous state of the well, and a model of the well built by a petroleum engineer. Unfortunately the model of the well wasn't always up to date (pump was replaced, etc..), so we needed to be able to replay all of the sensor data into the well when a model was retroactively c…

it sounds pretty straightforward to implement with basic crud too, though. you'd just need an inserted timestamp field so that you can rerun the analysis with

    where inserted >= the_date
    order by inserted

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

#70

Post by randolorian »

holoduke wrote: post #59
lmm wrote: post #45

Earlier quoted context omitted.

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.

A proper event storage solution will have optimistic concurrency built in.
Post reply on HN