Eventual Consistency

A user creates hop.example/q9Tz in Mumbai and taps it on their phone a second later. The phone reaches Frankfurt, which replies "link not found". Two seconds later it works. Nothing is broken: Hop is eventually consistent, and the user saw the "eventually" part.

The rule

Copies may disagree for a while; stop writing and they agree.

With eventual consistency, a write lands on one copy first and spreads to the others asynchronously — in the background, after the writer has been told "done". During that short window, called replication lag, different copies can give different answers. Once the write has spread and no new writes arrive, every copy holds the same value.

It is everywhere:

• DNS: change a domain's address, and resolvers around the world pick it up over minutes or hours.
• Email: a message can reach your laptop before your phone.
• Hop's regions: a new link reaches the other region within a second or two.

What you gain: fast writes (no waiting for distant copies) and availability (each region keeps answering during a network split). What you pay: short windows of stale reads.

The shortcut

Ask: "Is a few seconds of stale data acceptable here, and who will notice it?" Usually the only person who notices is the one who just wrote — so protect them.

The trap is assuming "eventually" means "slowly". Usually the lag is milliseconds to seconds. The design question is not how long, but whether anyone is harmed during it.

Drills

Answer fast — trust the rule.

Remember

• Copies may disagree for a while; stop writing and they agree.
• Shortcut: find who notices the lag — usually the writer — and give them read-your-writes.
• Trap: hearing "eventually" as "slowly"; lag is usually milliseconds to seconds.