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
A cache is a copy that can be lost and is allowed to be wrong for a while; a database is the truth that cannot be lost. Caches buy read latency and fan-out at the price of invalidation; the database pays for durability and consistency with slower reads.
| Cache (Redis / CDN / in-process) Caching Architecture | Database Database · What a Database Actually Is | |
|---|---|---|
| Use when | Reads dominate, the same keys are read far more often than written, and a slightly stale answer is acceptable — sessions, product pages, computed feeds, rate-limit counters. | The data must survive a restart, be queried by more than its key, or be correct at the moment it is read — balances, orders, inventory. |
| Avoid when | The only copy of durable data would live in the cache, or the read is already 2 ms from a well-indexed table. | Every page load hits the database for the same hot rows and the primary is at 90% CPU; add a cache in front, do not scale the primary. |
| Complexity | TTLs, invalidation, stampede protection, hot keys, negative caching, a second system whose failure changes latency 10×. | Schema, indexes, transactions; well understood and one system. |
| Operational cost | Memory sized to the working set; eviction policy; cluster mode for scale; a cold cache after a restart is a database load spike. | Storage, replication, backups, vacuum; the primary's write throughput is the ceiling. |
| Failure modes | Stale reads after a write, a stampede when a hot key expires, thousands of keys expiring together at midnight, a hot key on one shard, cache down → database overwhelmed. | Table scans without indexes, lock contention, replication lag on replicas, a single primary saturated by reads that a cache would have absorbed. |
| Data flow | Read: cache hit returns; miss → database → populate. Write: database, then invalidate or update the cache | Read and write go to the engine; replicas serve reads with lag |
| Consistency | Bounded staleness by TTL, or explicit invalidation | Transactional; read-your-writes on the primary |
| Observability | Hit ratio, eviction rate, p99 on miss, key hotness | Query latency, lock waits, replication lag, buffer cache hit ratio |