Architecture Tradeoff Explorer
Every comparison answers the same five questions — use when, avoid when, complexity, operational cost, failure modes — so the decision is about your constraints, not the fashion of the year.
Monolith vs MicroservicesREST vs GraphQLREST vs gRPCSynchronous call vs Asynchronous (queue)Relational (SQL) vs NoSQL (document / key-value)Queue (point-to-point) vs Pub/Sub (topic)Event-driven vs Request/responseCache (Redis / CDN / in-process) vs DatabaseCQRS vs CRUDEvent sourcing vs State storage
CRUD reads and writes one model through one interface; CQRS splits commands (write model) from queries (read models projected from events). CQRS solves read/write shapes and scaling that diverge; for most applications CRUD with good indexes and a few read queries is the right answer.
| CQRS CQRS | CRUD Database · SELECT, FROM, WHERE, ORDER BY, LIMIT | |
|---|---|---|
| Use when | Reads and writes have different shapes or scale (a normalised write model, a denormalised feed read 1,000× more), or several read models serve different screens. | One model serves both sides fine: forms in, tables out, joins at read time. The default for most applications. |
| Avoid when | The team cannot explain why the read model may lag the write model, or the UI reads the projection immediately after a command and shows the stale state. | Reads need a shape the normalised model cannot serve without twelve joins, or reads must scale independently of writes. |
| Complexity | High: two models, events or change capture between them, projection code, rebuilds, eventual consistency in the UI. | Low: one schema, one ORM or query layer. |
| Operational cost | Projection lag to monitor, rebuild tooling, two stores to back up and keep consistent. | One database; read replicas when reads outgrow the primary. |
| Failure modes | A read model showing an order that does not exist yet, a projection that fell behind for hours, a rebuild that takes a day, two models drifting. | A read query that grows to twelve joins and 400 ms; write contention on tables that serve reads. |
| Data flow | Command → write model → event → projector → read model ← query | Request → one model → response |
| Consistency | Eventual between write and read models | Immediate; one transaction |
| Middle ground | CQRS-lite: separate read queries and DTOs over the same database | Materialised views refreshed on a schedule |