The part people underestimate is how much organizational discipline event sourcing quietly demands.

Technically, sure, you can bolt an append-only table on Postgres and call it a day. But the hard part is living with the consequences of “events are facts” when your product manager changes their mind, your domain model evolves, or a third team starts depending on your event stream as an integration API.

Events stop being an internal persistence detail and become a public contract. Now versioning, schema evolution, and “we’ll just rename this field” turn into distributed change management problems. Your infra is suddenly the easy bit compared to designing events that are stable, expressive, and not leaking implementation details.

And once people discover they can rebuild projections “any time”, they start treating projections as disposable, which works right up until you have a 500M event stream and a 6 hour replay window that makes every migration a scheduled outage.

Event sourcing shines when the business actually cares about history (finance, compliance, complex workflows) and you’re willing to invest in modeling and ops. Used as a generic CRUD replacement it’s a complexity bomb with a 12-18 month fuse.

▲

mrkeen 2 hours ago | parent | next [-]

> Event sourcing shines when the business actually cares about history (finance, compliance, complex workflows)

Flip it on its head.

Would those domains be better off with simple crud? Did the accountants make a wrong turn when they switched from simple-balances to single-entry ledgers?

▲

javier2 an hour ago | parent | prev | next [-]

This. This is also a reason why its so impressive google docs/sheets has managed to stay largely the same for so long

▲

mexicocitinluez 2 hours ago | parent | prev [-]

> or a third team starts depending on your event stream as an integration API.

> vents stop being an internal persistence detail and become a public contract.

You can't blame event sourcing for people not doing it correctly, though.

The events aren't a public contract and shouldn't be treated as such. Treating them that way will result in issues.

> Used as a generic CRUD replacement it’s a complexity bomb with a 12-18 month fuse.

This is true, but all you're really saying it "Use the right tool for the right job".

▲

simonw an hour ago | parent | next [-]

> You can't blame event sourcing for people not doing it correctly, though.

You really can. If there's a technology or approach which the majority of people apply incorrectly that's a problem with that technology or approach.

▲

anthonylevine an hour ago | parent [-]

No you can't.

You can blame the endless amount of people that jump in these threads with hot takes about technologies they neither understand or have experience with.

How many event sourced systems have you built? If the answer is 0, I'd have a real hard time understanding how you can even make that judgement.

In fact, half of this thread can't even be bothered to look up the definition of CQRS, so the idea that "Storing facts" is to blame for people abusing it is a bit of a stretch, no?

▲

simonw 31 minutes ago | parent [-]

I've not run an event sourcing system in production myself.

This thread appears to have stories from several people who have though, and have credible criticisms:

https://news.ycombinator.com/item?id=45962656#46014546

https://news.ycombinator.com/item?id=45962656#46013851

https://news.ycombinator.com/item?id=45962656#46014050

What's your response to the common theme that event sourcing systems are difficult to maintain in the face of constantly changing product requirements?

	▲	anthonylevine 8 minutes ago \| parent [-]
		I think having constantly changing product requirements would certainly make it difficult, but that makes all development more difficult. In fact, I think most complexity I create or encounter is in response to trying to future-proof stuff I know will change. I'm in healthcare. And it changes CONSTANTLY. Like, enormous, foundation changes yearly. But that doesn't mean there aren't portions of that domain that could benefit from event sourcing (and have long, established patterns like ADT feeds for instance). One warning I often see supplied with event sourcing is not to base your entire system around it. Just the parts that make sense. Blood pressure spiking, high temperature, weight loss, etc are all established concepts that could benefit from event sourcing. But that doesn't mean healthcare doesn't change or that it is a static field per se. There are certainly parts of my system that are CRUD and introducing event-sourcing would just make things complicated (like maintaining a list of pharmacies). I think what's happening is that a lot of hype around the tech + people not understanding when to apply it is responsbile for what we're seeing, not that it's a bad pattern.

▲

zknill 2 hours ago | parent | prev [-]

> You can't blame event sourcing for people not doing it correctly, though.

Perhaps not, but you can criticise articles like this that suggest that CQRS will solve many problems for you, without touching on _any_ of its difficulties or downsides, or the mistakes that many people end up making when implementing these systems.

	▲	anthonylevine an hour ago \| parent [-]
		CQRS is simply splitting your read and write models. That's it. It's not complicated or complex.