3 ms·
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 desig
by zknill 11mo ago
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 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.