Pattern · seen in 2 breakdowns across 2 companies

Master-Only Reads

consistency

Definition

Serve every production read from the primary; replicas exist for failover, backups, and offline export, never for traffic. The rule buys read-your-writes determinism by construction: replica lag cannot corrupt application logic if no application logic ever observes a replica. Adopters state it as law learned two ways — as a policy against a whole class of intermittent, cache-entangled lag bugs, or as the fix for a specific correctness hole where stale reads of coordination state (idempotency records, locks, leases) re-create the very failure the state exists to prevent.

Boundary against read-replica scaling: that pattern spends consistency to buy read throughput and accepts lag as a managed quantity; this one refuses the trade, and recovers throughput elsewhere — typically by sharding the primary, which is why the two patterns travel together. The strongest applications are correctness-critical reads: state whose staleness changes a decision, not just a display.

When it applies

01Coordination and correctness state — idempotency keys, leases, dedupe records — where a stale read causes a wrong action, not a stale page
02Sharded fleets where per-primary load is already bounded, making replica read offload unnecessary
03Systems whose lag bugs have proven intermittent and expensive to diagnose, and whose owners prefer paying in hardware

Tradeoffs

Read capacity equals primary capacity: scaling reads means splitting shards or upgrading machines, not adding replicas
The replica fleet becomes pure insurance — real hardware serving zero requests on the average day
Reads that could genuinely tolerate staleness (analytics, feeds) pay full price unless carved out through a separate path

The same move, 2 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Airbnb
Airbnb Engineering
2019
Airbnb reaches this rule through the sharpest possible failure. If the idempotency tables are read from a replica (a copy that trails slightly behind the authoritative master), a correct retry can turn into a double charge: the payment succeeded and was recorded on master, but the retry reads a replica that hasn't caught up, sees no record, and runs the payment again. A few seconds of lag equals a double charge. So Orpheus reads and writes only on master, and wins back the lost scale by sharding on the idempotency key. Pinterest arrives at the same rule from a different angle: replicas are for surviving disaster, not for serving reads. Read the breakdown →
Pinterest
Pinterest Engineering Blog
2015
The other system in this collection with the same rule is Airbnb's Orpheus. Pinterest states it as operational law: standbys lag, lag breeds strange caching bugs, and production never reads from a standby. Airbnb reaches the same rule from a sharper wound, where reading a lagged replica turns a correct, safe-to-repeat retry into a double charge. Same conclusion from two directions: replicas are for disaster, not for reads. Read the breakdown →

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.

Ambiguous failure under retryAIRBNB →Single-table scaling ceilingPINTEREST →