CQRS without event sourcing: a simpler approach?
Diego Dubois
·27 views
we're considering adopting cqrs to improve query performance and simplify our write models, but we want to avoid the complexity of full event sourcing. our idea is to have a traditional relational database (postgresql) for writes, and then use change data capture (like debezium) to push updates to a separate read model, maybe an elasticsearch cluster, that's optimized for queries. this would give us separate read and write concerns without the full commitment to an event store. has anyone gone down this path of cqrs without event sourcing? what were the main challenges or pitfalls? are there specific consistency guarantees or operational complexities that we might be overlooking with this kind of setup?
5 comments