skip to content

CQRS

10 roadmaps34 questions

Separating the write model from the read model so each is shaped for its job: commands, projections, and the gap in between. Interviewers probe whether you can say when it is not worth it.

part ofEvent-driven architecture & messagingoverview, primer and where to startread it →
on this pageshow

explore

questions

page 2 of 2

A team running a CQRS system backed by Event Sourcing wants to add a brand-new read model over two years of historical order data, and separately needs to fix a bug in an existing projection's logic. What does deriving all read models from the event log make possible here that a 'read replica of the write database' approach would not, and what operational risks come with exercising that capability?

level: principalimportance: should knowfreq 50%

basics

~30 s

Because every past change was saved as an event, not thrown away, the team can build a new report over years-old data by replaying all those old events through brand-new logic, as if they were just now happening — something a normal database copy can't do, since it only ever has today's current numbers. The risk is that replaying millions of old events takes real time and computing power, and can strain the system if done carelessly.

open as a page

A read-model projection has a bug that has been silently producing wrong denormalized data for three months. What is the safe way to fix and recover this in production, and what design decisions made earlier would have made this easier?

level: principalimportance: should knowfreq 35%

basics

~20 s

Fix the bug in the code that builds the read model, then re-run that building process from scratch so the read model gets recomputed correctly, instead of hand-editing the wrong data. This only works cleanly if the real source of truth was never lost, only the derived copy.

open as a page

You're advising several teams across an organization on whether to adopt CQRS for their services. What decision framework would you give them to evaluate the trade-off consistently, and how would you handle a team that already adopted CQRS but the benefit never materialized?

level: principalimportance: should knowfreq 35%

basics

~20 s

Give teams a checklist of concrete signals (read/write ratio, shape mismatch, independent scaling need) instead of letting them decide on gut feel, and if a team adopted it without those signals, help them measure the actual cost/benefit and consider simplifying back to one model.

open as a page

At scale, a projection consumes events from a partitioned stream (e.g., a Kafka topic with many partitions) where global ordering isn't guaranteed across partitions, only within each one. How does this constrain how you key and design a projection handler, and what breaks if you get it wrong?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

When a stream is split into partitions for scale, events are only guaranteed to arrive in order within the same partition, not across all of them. So a projection has to make sure all events about the same thing, like the same customer or order, always land in the same partition, or it might process them out of order and end up with wrong, garbled results.

open as a page

showing 31–34 of 34