Weak Consistency

Hop's dashboard shows a live "clicks in the last minute" counter. It updates hundreds of times a second, and nobody will sue if it is off by three. Paying for perfect accuracy here would be wasted money. That is the home of weak consistency.

The rule

After a write, a read might see it — no promise, no apology.

With weak consistency, the system does its best but guarantees nothing. A write may show up in later reads, show up late, or be lost entirely.

It fits data that is approximate or short-lived, where being current matters more than being complete:

• A live video or voice call. If a packet is lost, the call does not rewind to replay it; it moves on.
• A live multiplayer game. You care where the other player is now, not where they were 200 ms ago.
• A best-effort in-memory cache or counter that may drop values under pressure or on restart.

For Hop, the per-minute click counter lives in memory on each server. If a server restarts, that minute's count restarts too. The dashboard is briefly wrong, and nobody is harmed.

The prize is speed and simplicity: no waiting for other copies, no retries, no coordination.

The shortcut

Ask: "If this write vanished, would anyone notice tomorrow?" No → weak consistency is fine. Yes → you need a stronger promise.

The trap is letting weak consistency leak into data that matters. A counter kept "just for display" often ends up feeding invoices later — check where data travels before you weaken it.

Drills

Answer fast — trust the rule.

Remember

• After a write, a read might see it — no promise.
• Shortcut: "if this write vanished, would anyone notice tomorrow?" No → weak is fine.
• Trap: weak data quietly turning into billing or record-keeping data.