CQRS
Also known as: Command Query Responsibility Segregation
Command Query Responsibility Segregation (CQRS) splits the write model from the read model. Commands mutate state through a narrow validated path; queries read from projections optimised for the access pattern. The benefit is independently scalable reads and writes, plus the freedom to denormalise reads aggressively. The cost is two models and the synchronisation between them.
Concepts that travel with this one.
Architecture rarely lives in isolation — these are the terms that come up in the same conversation.
Event Sourcing
Event sourcing persists every change as an immutable event in an append-only log rather than overwriting current state. Current state is derived by replaying events. The pattern shines for audit, debugging, and integration — every state change is reproducible — but it adds projection and consistency complexity. TantraDev uses it where audit-completeness or replay matter more than write simplicity.
Eventual Consistency
Eventual consistency is a relaxation of the strong-consistency guarantee: writes propagate asynchronously across replicas, and readers may briefly observe stale state, but the system converges to a single value if writes stop. The CAP-theorem trade-off is throughput and availability under partition. TantraDev uses eventual consistency knowingly — never as a side effect — and always with a documented staleness window.
Building a system where CQRS is the load-bearing decision?
30 minutes on the phone, one page in your inbox — what to build, what to skip, what it will cost. You keep the audit even if we are not the right fit.