CQRS: Do you really need two databases?
summary
Argues that CQRS does not mandate two databases but that pragmatic choices decide persistence: event sourcing often pairs an event store + projection DB, projections can live in memory or Redis instead of a separate database, and RavenDB can act as one system because it is a key‑value store with an indexing engine; claims independent scaling of reads and writes and reports typical eventual consistency gaps at 10–50 ms while estimating 80–90% scenarios tolerate eventual consistency.
AI-written summary · about
chapters (22)
- 0:00Projects off autopilot
- 1:23Developers change systems not build them
- 2:29Software complexity
- 5:16Essential vs accidental
- 6:20Pure functions and side effects
- 9:33Unit testing isolation
- 13:06Architecture limitations
- 13:51Command Query Separation origins
- 16:00CQS in practice
- 17:25CQS to CQRS evolution
- 18:53CQRS with two DBs and event sourcing
- 20:46Eventual consistency in systems
- 21:51Projections and caching pragmatism
- 22:57Avoiding CQRS cargo cult
- 24:01Single vs multiple databases in CQRS
- 25:25CQRS and async thinking
- 26:29CQRS without event sourcing
- 27:10When CQRS unnecessary
- 27:32Why devs love change
- 28:17Principles behind modern tech
- 29:01Pragmatism over dogma
- 29:44How many databases needed
related talks
59mCQRS pitfalls and patterns
55m7 Reasons why your microservices should use Event Sourcing & CQRS
40m7 Reasons why your microservices should use Event Sourcing & CQRS
17m7 Reasons why your microservices should use Event Sourcing & CQRS
01h 25mBuilding microservices with event sourcing and CQRS
51mMicroservices Data Patterns: CQRS & Event Sourcing
46mMicroservices Data Patterns: CQRS & Event Sourcing
04mCommand Query Responsibility Segregation