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
Relational databases make relationships, ad-hoc queries and invariants cheap; document and key-value stores make one access pattern fast by promising nothing else. Choose by access pattern, not by imagined scale.
| Relational (SQL) Database · SQL vs NoSQL: Choosing a Data Model | NoSQL (document / key-value) Database · Document Databases: Embed or Reference | |
|---|---|---|
| Use when | Data has relationships, queries are not all known up front, and invariants across rows matter — orders, accounts, inventory. The default for the system of record. | The unit of work is one aggregate read and written whole with a variable shape, or pure get/put by key at very high rate — sessions, carts, catalogue documents, rate-limit counters. |
| Avoid when | The only access is get/put by key at a rate one machine cannot serve, and you would never query by another attribute. | You keep writing application-side joins, need multi-document transactions, or chose it for scale you have not measured. |
| Complexity | A schema, migrations, indexes, a planner to understand; one system answers most questions. | Simple API, but every relationship and invariant moves into application code; schema-on-read means every reader handles every historical shape. |
| Operational cost | Vertical scaling then read replicas cover most workloads; sharding is a project. | Horizontal partitioning is built in; consistency, backups and secondary indexes vary by product and must be understood per product. |
| Failure modes | A missing index turns a read into a table scan under load; lock contention on hot rows; a single primary as the write ceiling. | Hot partitions on a bad key; unbounded embedded arrays; drift between denormalised copies with no constraint to catch it; the only durable copy of data living in a cache. |
| Data flow | Query → planner → indexes → rows joined and filtered in the engine | Key → partition → one document or value; joins happen in the application if at all |
| Consistency | ACID transactions across tables | Per document or per key; cross-document atomicity limited or absent |
| Tooling | SQL, EXPLAIN, decades of tooling and people | Product-specific query languages and operational knowledge |