Tag: Architecture

Twenty frameworks is a lot to memorize — until you notice they are answers to only four questions. How consistent must the data be? How much traffic is coming? What happens when something breaks? And how should work flow between services?

Sort the twenty into those four families and the list stops being a list. It becomes a checklist you can run in any design review.

Family 1: Consistency & Data — “What is the truth, and where does it live?”

CAP Theorem. When a network partition splits your system, you must choose: stay consistent (every read sees the latest write) or stay available (every request gets an answer, possibly stale). You cannot have both during a partition. This is the first fork in every distributed design.

PACELC Model. CAP only speaks during failures. PACELC adds the everyday case: else (no partition), you still trade Latency against Consistency. It is CAP for real life, because most days nothing is broken — and you are still making the trade.

Database Sharding. Split one large dataset across many databases — by user ID, by region, by any key that spreads the load evenly. Reach for it when a single database genuinely cannot carry the workload, not before.

Replication. Copy data across nodes so the system survives losing one. Leader–follower when one writer is enough; multi-leader when writes must happen in more than one place. Replication buys reliability and read scale; it charges you in consistency headaches.

Consistent Hashing. The ring that decides which node owns which key — designed so that adding or removing a node moves only a small slice of the data, not everything. It is why sharded systems can scale without a weekend of rebalancing.

Family 2: Traffic & Scale — “Too many requests, not enough server”

Load Balancing. Spread incoming traffic across servers: round-robin for simple cases, least-connections when requests vary, hashing when a user must land on the same node. The goal is boring — no server drowning while its neighbor idles.

Caching Strategies. Keep frequently read data close and fast. Cache-aside (the app checks the cache, fills it on a miss), write-through, write-back — the variations are about when the cache and the database agree.

Write-Through Caching. The specific pattern worth naming on its own: every write updates the cache and the database together, so the cache is never stale. You pay a little write latency to buy reads you can trust.

Rate Limiting. Cap how many requests a client may make in a window. It protects availability, enforces fairness between customers, and turns abuse into a polite 429 instead of an outage.

Back-of-the-Envelope Estimation. Rough capacity math with stated assumptions: users × requests × size = storage, bandwidth, servers. Five minutes of arithmetic that kills unbuildable designs before they consume a quarter.

Family 3: Staying Alive — “Something will fail; then what?”

Circuit Breaker. When a downstream service keeps failing, stop calling it for a while — fail fast, let it recover, test it with a trickle before reopening the floodgates. Named after the electrical part because it does the same job: it keeps a fault from burning down the house.

Retry Patterns. Failed requests often succeed on a second attempt — but retry with exponential backoff and jitter, or a thousand clients retrying in lockstep become the outage.

Bulkhead Pattern. Partition your own resources the way a ship’s hull is partitioned: separate thread pools per dependency, so one slow service floods only its own compartment instead of sinking the whole application.

Leader Election. In a cluster, exactly one node coordinates. Leader election picks that node dynamically and replaces it when it dies — the quiet mechanism behind half the systems in this list.

Gossip Protocol. Nodes spread state by chatting with random peers, the way news spreads through an office. No central coordinator, no bottleneck — large clusters stay informed eventually, which is usually enough.

Family 4: Flow & Coordination — “How does work move and stay correct?”

Event-Driven Design. Services react to events instead of calling each other directly. The producer does not know or care who consumes — which is what decoupling actually means.

CQRS. Separate the write model from the read model (Command Query Responsibility Segregation). When reads and writes have wildly different shapes and volumes, optimizing one shared model serves neither.

Saga Pattern. A distributed transaction built from local transactions plus compensating actions. Book the flight, charge the card, reserve the hotel — and if step three fails, undo steps one and two. No two-phase commit across services; consistency by choreography instead.

Idempotency. Design operations so running them twice has the same effect as running them once. It is what makes retries, duplicate deliveries, and nervous users with double-clicks safe — the foundation every payment API stands on.

Event Sourcing. Store the events (what happened) instead of the final state. Current state is rebuilt by replaying history — which gives you a complete audit trail and time travel as side effects. Powerful, and heavier than most systems need.

The bottom line

Nobody recalls twenty frameworks under pressure. They recall four questions — consistency, traffic, failure, flow — and pull the right tool from the right family. Learn the families and the twenty names will attach themselves.

Want the whole set as a printable reference? The free toolkits at aideeva.com/free-toolkits/ include the AI Engineering Iceberg Poster and architecture cheat sheets built the same way — grouped to be remembered.