21–30 of 55 posts
Earlier quoted context omitted.
- Write side is a Postgres INSERT - Read side is a SELECT on a Postgres view
I 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
That's EXACTLY what CQRS.
I think you might struggle to understand CQRS.
Earlier quoted context omitted.
> 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 consistenc…
Yes, 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 mo…
Earlier quoted context omitted.
> 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 consistenc…
Please 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 w…
This is flat out false.
[flagged]
[flagged]
> 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-1…
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.
[flagged]
Earlier quoted context omitted.
> 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-1…
> 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.
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?
You get similar levels of historical insight, with the disadvantage that to replay things you might need to put a little CLI or script together to infer commands out of the audit log (which if you do a lot, you can make a little library to make building those one off tools quite simple - I've done that). But you avoid all the many well documented footguns that come from trying to run an event sourced system in a typical evolving business.
Earlier quoted context omitted.
> 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.
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 "Sto…
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?
[flagged]
I already refrained from introducing event sourcing to tackle wierd dependecies multiple time just by justaposing the amount of discipline that the team has that lead to the current state vs the discipline that is required to keep the event source solution going.