Scale Data Safely: Replicas, Partition Keys, and Replication Lag
Read replicas and partition keys scale a database, but replication lag, hot partitions, and cross-shard writes change correctness. This interactive lesson routes storefront reads by freshness and compares customerId, orderId, and productId keys. Covers: Read-after-write consistency, replication lag symptoms, primary pinning, hot partitions, cross-shard transactions, reservation states, idempotency keys, compensating actions. Practice: Partition keys. Prerequisites: Database replication and sharding concepts.
We'll cover the following...
An interviewer hears a candidate say, “Add read replicas and shard by customerId; reads scale and everything stays consistent.” The missing signal is not database vocabulary. It is whether the candidate can separate capacity from correctness. For the seasonal storefront, catalog pages can usually show slightly older product details. Order history may also tolerate a short delay. An order-confirmation page and an inventory display immediately after checkout require read-after-write, meaning the read must reflect the completed write.
A read replica is a copy of primary database data that serves read traffic. It can absorb catalog and historical-order reads, but it may apply changes after the primary commits them. That delay is replication lag. A confirmation request routed to a lagging replica can briefly report that a just-created order does not exist. Replicas help reads, but they introduce new timing and routing decisions. Inspect how primary-to-replica delay changes each ...