Between strong and eventual sits a whole spectrum.
Strong acts like one copy. Eventual only promises replicas agree once writes stop. Most features need something in between, far cheaper than strong.
Eventual = strong, a bit later?
Bad: A small delay
Replicas catch up fast, so reads are just slightly late.
Good: No promise meanwhile
No deadline. Meanwhile reads can go backwards or mix values that never coexisted.
18
scores you could read for one 2–5 game
Eventual reads of two numbers can mix versions: 3 visitor values × 6 home values, even a visitors’ lead that never happened. Consistent prefix allows only 8.
Fix it with a version token
The write returns its log position, v42. Later reads carry it. A replica still at v41 forwards to the leader instead of answering.
One baseball score, many readers: the scorekeeper, the umpire, a radio reporter, a fan checking stats.
The trick
Consistency belongs to the read, not the table. The same two numbers need four different guarantees.
In a sale, browsing is eventual and the final step is strong.
The catalogue shows “3 left” from a replica. A compare-and-set on the stock row decides who actually gets one.
Where the cheap tricks stop working
- Session tokens live in one client, not your laptop
- A cache or CDN in front ignores tokens
- An async leader that dies early strands the token
Remember
Strong acts like one copy; eventual only converges. Choose per read path: ledger strong, profile read-your-writes, comments causal, likes eventual.