System Design Foundations
Consistency Models
A spectrum from strong (every read sees the latest write) to eventual (replicas converge with no bound on when) — with practical stops in between that most real systems actually rely on.
- Strong (linearizable) consistency: reads always reflect the most recent acknowledged write, as if there were a single copy of the data — requires coordination, costs latency
- Eventual consistency: replicas converge given enough time and no new writes, but offer no guarantee about when — cheap and highly available, but stale reads are possible
- Causal consistency: preserves cause-and-effect ordering (a reply is never visible before the comment it replies to) without paying for full linearizability
- Session guarantees — read-your-own-writes and monotonic reads — are a practical middle ground: a user never sees their own change disappear or time travel backward
- Stronger consistency generally means higher write latency and reduced availability under partition (Cap Theorem) — the choice is a tradeoff, not a strictly-better option
| Model | Guarantee | Cost |
|---|---|---|
| Strong / linearizable | Every read sees the latest write | Highest — coordination on every op |
| Causal | Cause precedes effect, always | Moderate — needs dependency tracking |
| Read-your-writes | You always see your own recent writes | Low — sticky routing or version tokens |
| Eventual | Converges given time, no ordering promised | Lowest — no coordination needed |
class VersionedSession {
private volatile long lastWriteVersion = 0;
long recordWrite(long versionFromPrimary) {
lastWriteVersion = Math.max(lastWriteVersion, versionFromPrimary);
return lastWriteVersion;
}
// Replica read waits (or retries) until its applied version >= lastWriteVersion.
boolean replicaCanServe(long replicaAppliedVersion) {
return replicaAppliedVersion >= lastWriteVersion;
}
}