Strong Consistency

Hop lets paying customers claim custom aliases like hop.example/sale. If two people in two regions both get told "it's yours", Hop has a real problem: one of them will send their customers to the other's page. Some data can never be briefly wrong. For that, you need strong consistency.

The rule

Once a write is confirmed, every later read sees it — everywhere.

With strong consistency, the system behaves as if there were only one copy. After "done", no reader anywhere can see the old value.

To get there, copies must coordinate before confirming: the write is copied synchronously to other replicas, or a majority of replicas agree on it, before the writer hears "done". Databases do this with synchronous replication, transactions and consensus protocols.

It fits data where a wrong answer is worse than a slow one:

• account balances and payments
• stock of the last item in a shop
• unique names: usernames, Hop's custom aliases
• locks and leader choice

The price is paid on every write: latency (waiting for other copies, sometimes across continents) and availability (if copies cannot reach each other, the write must fail — the CP side of CAP).

The shortcut

Put the three levels on one line and slide along it only as far as the data demands:

weak → eventual → strong: faster and more available on the left; more correct and more expensive on the right.

The trap is making everything strong "to be safe". You then pay coordination costs on the busiest paths for data that never needed them.

Drills

Answer fast — trust the rule.

Remember

• Once a write is confirmed, every later read sees it — everywhere.
• Shortcut: weak → eventual → strong; slide right only as far as the data needs.
• Trap: making everything strong and paying for it on the busiest paths.