3 ms·
Anyone who's built, run, evolved, and operated any reasonably sized event sourced system will know it's a total nightmare. Immutable history sounds like a good
by zknill 11mo ago
Anyone who's built, run, evolved, and operated any reasonably sized event sourced system will know it's a total nightmare.
Immutable history sounds like a good idea, until you're writing code to support every event schema you ever published. And all the edge cases that inevitably creates.
CQRS sounds good, until you just want to read a value that you know has been written.
Event sourcing probably has some legitimate applications, but I'm convinced the hype around it is predominantly just excellent marketing of an inappropriate technology by folks and companies who host queueing technologies (like Kafka).
- anthonylevine 11mo ago> CQRS sounds good, until you just want to read a value that you know has been written. This is for you and the author apparently: Prating CQRS does not mean you're splitting up databases. CQRS is simply using different models for reading and writing. That's it. Nothing about different databases or projections or event sourcing. This quote from the article is just flat out false: > CQRS introduces eventual consistency between write and read models: No it doesn't. Eventual consistency is a design decision made independent of using CQRS. Just because CQRS might make it easier to split, it doesn't in any way have an opinion on whether you should or not. > by folks and companies who host queueing technologies (like Kafka). Well that's good because Kafka isn't an event-sourcing technology and shouldn't be used as one.
- zknill 11mo agoPlease explain how you intend to use different models for reading and writing without there being some temporal separation between the two? Most all CQRS designs have some read view or projection built off consuming the write side. If this is not the case, and you're just writing your "read models" in the write path; where is the 'S' from CQRS (s for segregation). You wouldn't have a CQRS system here. You'd just be writing read optimised data.
- azkalam 11mo ago- Write side is a Postgres INSERT - Read side is a SELECT on a Postgres view
- zknill 11mo agoI think you might struggle to "scale the read and write sides independently". It's a real stretch to be describing a postgres view as CQRS
- anthonylevine 11mo agoHuh? That's EXACTLY what CQRS. I think you might struggle to understand CQRS.
- andersmurphy 11mo agoSqlite can scale CQRS to 100000 events per second on a relatively small VPS. That's 10x what the author achieves with postgres. You can scale them independently in that you can control the rate at which your views are read and the batch size of your updates. The whole big win wirh CQRS is it allows for very efficient batching.
- azkalam 11mo agoBut only one server can access each SQLite at a time?
- mrkeen 11mo agoI've heard worse, e.g. You use POST for your Cs and GET for your Qs. Tada!
- deleted 11mo ago[deleted]
- anthonylevine 11mo ago> Most all CQRS designs have some read view or projection built off consuming the write side. This is flat out false.
- mrkeen 11mo ago> Just because CQRS might make it easier to split Or segregate even.
- mrsmrtss 11mo agoYes, I don't know where the misconception that CQRS or Event Sourcing automatically means eventual consistency comes from. We have built, run, evolved, and operated quite a few reasonably sized event sourced systems successfully, and these systems are running to this day without any major incidents. We added eventually consistent projections where performance justified it, fully aware of the implications, but kept most of the system synchronous.
- anthonylevine 11mo agoI think people lump CQRS, Event Sourcing, and event-driven into this a single concept and then use those words interchangeably.
- andersmurphy 11mo agoYup. It's a shame as amazing as event sourcing is it does come with complexity. On the other hand CQRS + single writer pattern on their owncan be a massive performance win because it allows for efficient batching of views and updates. It's also much simpler to implement than a fullblown event sourcing system.
- mrkeen 11mo agoIf you segregate your read and write, i.e put a (P)artition between them, and require writes to be (A)vailable when reads are down (and vice-versa), then you're either inconsistent, or eventually-consistent.