A separate read store is not the next mandatory CQRS step. It is useful when a screen, report, or read workload needs a shape that the transactional write model should not own.
For an order-tracking screen, a projection can keep one denormalized row with an order number, customer name, status, last-updated time, and total. That can remove repeated joins and let read traffic scale separately from command handling.
The trade-off is visible behavior. A command can commit before the projection updates, so the next read can be stale. Treat the write side as authoritative, make projections rebuildable, and state what the user should expect after a successful command. If a shared database and direct projection already work, keep them.
Top comments (0)