Replicas and what they are allowed to lag

Before you start

• Databases

  Queues and partitions sit around a primary database. That lesson covers the key and the index.

  Open lesson

Why it matters

A create can succeed moments before another machine serves the first redirect, and a machine can fail while that create is still moving through the system. Treating every reader alike either slows all reads or surprises the person who just created the link. The creator of x7Kp must open it immediately; a stranger may observe it up to about one second later.

The primary takes creates. Redirects should usually be served from a cache, and on a miss you may read a replica.

After the primary commits x7Kp, serve ordinary cache misses from asynchronous replicas, but pin its creator to the primary for a few seconds; that user sees x7Kp immediately while strangers may tolerate about one second of lag.

The primary commits create x7Kp, then streams log entries to read replicas asynchronously. A cache miss sent to a replica at log position 39 can miss x7Kp while the primary is already at 41; ordinary visitors accept this short stale window.

Remember that the creator recently wrote x7Kp and route that user’s reads to the primary for a few seconds. This supplies read-your-writes without making every redirect wait. A failover can lose any unreplicated tail entry, even one the primary acknowledged; strict durability requires synchronous replication, while idempotent retries repair detectable missing creates.