Pattern library

Reads dominate your workload, and every read hits a slow store (database, disk, network). Latency and load on the primary storage climb until the primary becomes the bottleneck.

Your application logic has to duplicate cache-management code everywhere it reads — check cache, on miss read DB, populate cache, return.

In cache-aside, cache and DB can diverge briefly on writes. You need stronger cache-consistency.

Write throughput is high; every write hitting the DB creates load. But you don't need writes to be durable in the DB immediately.

Cache-aside with writes populating the cache can pollute the cache with never-read data (write-heavy but read-rare content).

You want to broadcast an event to multiple consumers without coupling the producer to the list of consumers.

Tight coupling between services makes evolution painful. When service A directly calls service B, they must deploy together, know each other's contracts, and B's failures propagate to A.

Your write model and read model have very different needs. Optimizing for one hurts the other.

Traditional state-based storage loses history: you know the current balance, but not why it's that value. Auditing, replay, and temporal queries are hard.

You have a business transaction that spans multiple services or databases (place order → charge payment → reserve inventory → send confirmation). Two-phase commit is too slow, too coupling, and often not available across service boundaries.

You need to atomically update your database AND publish an event to Kafka. Two-phase commit isn't available; publishing before the DB commit risks phantom events; publishing after risks lost events on crash.

You want to derive downstream systems (search index, cache, analytics) from your primary database — but polling for changes is expensive and misses deletes.

Your dataset or write throughput has outgrown a single node. A single primary DB or single cache node can't hold the data or handle the QPS.

You need to shard keys across N nodes, but N changes over time (nodes added, removed, or failed). Naive hash-mod-N reshuffles almost everything on every change — cache is wiped, migration cost is huge.

One node can't handle all reads. And if the node dies, you lose everything.

You need HA and scale in multiple regions. Passive standby wastes capacity; leader-follower has one region doing all the writes.

You need HA but don't want the complexity or cost of active-active.

One event or write must be distributed to many consumers or write destinations.

You need to answer a query that requires data from multiple shards/services, and you need the aggregate result.

One misbehaving caller or workload consumes all your resources (threads, connections, memory) and starves everyone else.

A downstream service is unhealthy. Your service keeps calling it, waiting the full timeout on every call, exhausting your thread pool, and cascading the failure back to your callers.

Transient failures (network hiccup, brief overload) succeed on retry. Retrying immediately makes overload worse (retry storm).

Producers publish faster than consumers can process. Queues grow unbounded, memory fills up, and everything crashes.

One bad actor can consume all your capacity. And even good actors need bounds so you can capacity-plan.

Your system is overloaded. Continuing to accept work makes it worse (all requests get slow, none complete on time).

You have a legacy monolith you want to replace, but a big-bang rewrite is too risky.