Patterns Lab

Read and write workloads have different shapes and scaling needs. A single model becomes a bottleneck — writes need normalization, reads need denormalization.

Traditional DBs store current state only — you lose history. Event sourcing stores every state change as an immutable event. Current state = replay all events.

Complex queries (JOINs, aggregations) are too slow to compute on every read. Pre-compute and store the result.

Microservices sharing a single database creates tight coupling — schema changes break multiple services.

Different caching strategies for different read/write patterns. Wrong choice = stale data or unnecessary complexity.

Need to sync data between systems (DB to search index, DB to cache, DB to analytics) without coupling them or polling.

Need to update DB AND publish an event atomically. If you do DB write then publish, crash between them = lost event. If publish then write, crash = phantom event.

User updates profile then refreshes page and sees OLD data because read hit a stale replica. Breaks user trust.

Services directly calling each other = tight coupling, cascading failures, deployment dependencies. Events decouple producers from consumers — adding consumers needs zero producer changes.

Single consumer can't keep up with message queue throughput. Need multiple consumers processing messages in parallel.

Producer generates data faster than consumer can process. Without backpressure: queues grow unbounded → OOM, or messages silently dropped.

Not all messages/requests are equal. Urgent tasks should be processed before background work.

Downstream service failing? Continuing to call it wastes resources, cascades failures, and prevents recovery. Circuit breaker stops calling, fails fast, gives time to recover.

One failing component consuming all shared resources (threads, connections) and bringing down the entire system.

Transient failures (network blip, temporary overload) should be retried, but naive retry causes thundering herd on recovery.

System is overloaded — serving all requests slowly is worse than rejecting some quickly. Controlled degradation prevents total collapse.

Business transactions spanning multiple microservices can't use distributed transactions (too slow, tight coupling). Sagas break it into local transactions with compensating actions.

Need atomic transaction across multiple databases/services. Either ALL commit or ALL rollback.

Network timeouts cause clients to retry. Without idempotency, retry = duplicate operation (double charge, double order).

Single database can't handle the data volume or throughput. Need to split data across multiple nodes.

Some tasks must be done by exactly ONE node (writing to DB, coordinating locks, assigning work). Leader handles work, followers are standby. Challenge: detect failure + elect new leader without split-brain.

Databases must survive crashes without losing committed data. WAL: write intended changes to sequential log BEFORE modifying data pages. Sequential writes are 100x faster than random.

Need both real-time analytics AND historical batch analytics on same data. Single pipeline can't serve both efficiently.

Clients shouldn't call dozens of microservices directly. Need single entry point that handles auth, routing, aggregation.

Every service needs logging, monitoring, retries, TLS — duplicating this logic in every service is wasteful and inconsistent.

Every service needs retry logic, circuit breaking, monitoring for outbound calls. Ambassador handles this as a proxy.

In dynamic environments (containers, auto-scaling), service IP addresses change constantly. Clients can't hardcode addresses.

Large monolith needs migration to microservices. Big-bang rewrite is too risky. Strangler fig: incrementally replace pieces via proxy routing until monolith is empty.

Need to control how many requests a client can make. Different algorithms have different fairness and burst characteristics.

Testing set membership on billions of items is expensive. Bloom filter: "definitely NOT in set" or "probably in set" using only 1-2 bytes per element. Perfect for avoiding expensive lookups.

User follows 500 people — how to show latest posts from all 500 in their feed? Pre-compute (push) vs compute-on-demand (pull) with different perf trade-offs.

hash(key) % N means adding/removing a server remaps MOST keys (cache invalidation disaster). Consistent hashing: only ~1/N of keys remap when topology changes.