App servers are stateless behind a load balancer, across zones, so a dead one is removed by health checks and the others carry on (lessons 2.1, 2.2). State lives in replicated stores. Name anything that isn't replicated, and fix it. Mention how in-flight requests are handled: retried by the client with idempotency keys (lesson 1.5).

A replica is promoted (automatically, by a majority-based failover system so there can't be two leaders), and writes are redirected (lessons 2.5, 5.4, 6.5). With asynchronous replication, the last moments of writes can be lost. Wait for at least one replica in another zone if that's unacceptable. Old leaders are fenced so they can't accept stale writes.

Every call has a timeout and a share of the request's overall deadline. A circuit breaker stops calling a failing dependency, bulkheads stop it using up all workers, and a fallback keeps the page useful without it (lesson 6.1). A slow dependency is more dangerous than a dead one, because it ties up resources.

Traffic moves to other regions (DNS with a short TTL, or anycast); replicas there are promoted for the affected data. Cross-region replication is usually asynchronous, so a few seconds of writes may be lost. Surviving regions need spare capacity, and nothing must depend on a single region, especially things like authentication (lesson 5.5).

Every read now hits the database, possibly many times its usual load. Plan for it: replicated cache nodes, rolling restarts, warming before switching traffic, limiting concurrent database queries, and serving stale data where acceptable (lesson 2.4).

Redo the estimates at 10× (lesson 1.3) and compare with each component's limits (lesson 8.2). Usually it's database writes, then a hot key or partition, then bandwidth. Say which, and the next step: add replicas and caching for reads, partition for writes, a CDN for bandwidth.

List the main queries, pick the key that keeps the most frequent ones on one shard, and name what becomes cross-shard (lesson 5.1). Use many logical shards mapped to fewer machines so you can add capacity later without moving everything (lesson 5.2). Mention global uniqueness (a separate table) and hot shards.

On reads: short-lived local caches on app servers, replicated copies of the hot key, CDN for anything public. On writes: separate the action from the total (one row per like), shard or batch counters, and choose partition keys that spread the hot item's events (lesson 4.5). For feeds, the celebrity is pulled at read time rather than pushed (lesson 4.4).

Queues absorb bursts so work happens at a sustainable pace (lesson 4.1). Autoscaling is too slow for sudden spikes, so pre-scale for known events (lesson 2.1). Load shedding and rate limits protect the core when demand exceeds capacity (lessons 6.1, 6.3), and features degrade gracefully.

Write down the access patterns first (lesson 3.1). Relational when you need joins, constraints and transactions; wide-column for huge append-heavy writes read by key and time range; documents for self-contained objects; a search engine for text. It's often both: relational for core entities, plus a specialized store for one pattern.

The write went to the leader; the read went to a replica that hadn't applied it yet. Fix with read-your-writes: read from the leader for recent writers, or track the write's log position and only use replicas that have reached it (lessons 2.5, 5.3).

If you check availability and then write, both can succeed. Make the check and the claim one atomic operation on the single place that owns the data: a conditional update or a unique constraint, on the leader (lessons 1.4, 5.3). For high contention, split the inventory into pools or queue buyers.

For caches: delete on write after the transaction commits, keep a TTL as a safety net, and watch for the stale-set race (lesson 2.4). For search and other copies: avoid dual writes from the app. Use change data capture from the database's log, with idempotent, versioned updates (lesson 3.4).

Go feature by feature and pick the weakest guarantee each can live with: linearizable for uniqueness and money, read-your-writes for a user's own content, causal for conversations, eventual for counts and feeds (lesson 5.3). Weaker guarantees are cheaper and stay up during failures.

CAP is about what to do during a network partition: refuse some requests or risk inconsistency. Choose per operation, not per system: username claims refuse; likes are accepted and reconciled later (lesson 5.4). In normal operation, the everyday trade-off is latency versus consistency (PACELC).

Queues deliver at least once, so consumers must be idempotent: record message IDs in the same transaction as the work, or design operations that are naturally safe to repeat (lessons 4.1, 4.2). For external effects, pass an idempotency key to the other system.

Write the event into an outbox table in the same transaction as the change, and have a relay publish it to the queue or log (lesson 4.2). Consumers de-duplicate by event ID.

A timeout means the outcome is unknown. Clients send an idempotency key, generated before the first attempt and reused on every retry, so the server returns the first result instead of acting twice (lesson 1.5). For payments, also query the status rather than guessing (lesson 7.3).

Prefer making the job idempotent, so two runs don't matter. If you need a single runner, use a lease from a consensus-backed system (etcd, ZooKeeper) with fencing tokens checked by whatever the job writes to, because a paused holder can't tell its lease expired (lessons 2.1, 6.5).

State the requirements (size, sortable, generated where, guessable or not), then compare auto-increment, UUIDv4, UUIDv7 and Snowflake (lesson 4.3). Mention unique machine IDs and clocks going backwards for Snowflake, and random keys' effect on index inserts.

Find where the time goes first: traces and percentiles, not averages (lessons 6.2, 6.4). The usual wins: fewer round trips and batching (lesson 1.2), a cache with a good hit ratio (lesson 2.4), an index (lesson 1.4), a CDN or a nearer region for distant users (lessons 2.3, 5.5), and doing slow work asynchronously (lesson 4.1).

Fan-out multiplies rare slowness, and garbage-collection pauses, queueing, background work and cache misses all add to the tail. Reduce the number of calls, hedge requests after the p95 wait (for safe-to-repeat reads), keep slow machines out of rotation, and return partial results within a deadline (lesson 6.2).

Push for normal accounts (precomputed feeds), pull for very large accounts, merged at read time: a hybrid. Mention the numbers behind it, the celebrity problem, feed storage limits, and that deletes and blocks are enforced at read time (lesson 4.4).

Rate limits by account, API key, device and target (not just IP), using a token bucket in a shared store, with 429 and Retry-After (lesson 6.3). Add challenges or review for sign-ups, and decide whether each limit fails open or closed if the limiter is down.

Define SLIs from the user's side (the share of requests that succeed quickly), set SLOs with error budgets, and alert on how fast the budget is burning, not on CPU (lesson 6.4). Use metrics for detection, traces to find where, logs to find why.

Rolling deploys behind the load balancer: mark a server not ready, drain its connections, shut down gracefully, start the new version, wait until ready, move on (lesson 2.2). Changes to APIs and data are backward compatible (lesson 1.5), and long-lived connection servers are restarted gradually with jittered reconnects (lesson 7.1).

Make additive, backward-compatible changes first; backfill in small batches while watching replication lag (lesson 2.5); switch reads and writes in steps; remove the old column last. Use tools or database features that avoid long locks.