CQRS: Split Catalog Reads From Checkout Writes and Own the Costs
Command Query Responsibility Segregation (CQRS) is an architecture pattern that separates the write model that accepts commands from the read model that serves queries. This hands-on lesson splits storefront catalog reads from checkout writes and weighs when CQRS repays its costs. Covers: Eventual consistency, acceptable staleness windows, read-your-writes for admin flows, idempotent projectors, projection lag alerts, read model rebuilds, when CQRS is overkill. Tools: Amazon DynamoDB, Amazon DynamoDB Streams. Practice: When should you not use CQRS. Prerequisites: Read replicas and system-of-record design.
We'll cover the following...
The interviewer asks whether we should scale the checkout database, add caching, or split reads and writes when catalog traffic overwhelms the database at peak. Command Query Responsibility Segregation (CQRS) separates the write model that accepts commands from the read model that serves queries. For the seasonal storefront, checkout remains on its correct system of record while catalog queries use a model shaped for low-latency browsing.
CQRS wins when catalog reads dominate, catalog queries need different indexes or document shapes, and each side must scale independently. It is overkill when the same store already meets read and write latency targets, catalog updates must appear immediately everywhere, or the team cannot own a projection pipeline and its ...