Cheat Sheet
The Cheat Sheet¶
The Problem All Three Solve¶
Multiple nodes. Data must be consistent across them. Nodes can fail. Networks can fail. How do you stay correct?
Your Postgres + LSN Solution¶
Topology One primary. N replicas. You manage everything in app code.
Write path Always primary. CP. Fails if primary unreachable. Never splits.
Read path
- Critical → LSN check in Redis → primary if replica behind → CP
- Non critical → replica directly → AP
During partition
- Primary side → works normally
- Replica side → serves stale data silently
- Defence → primary heartbeat + proxy health checks
Consistency granularity Per user, per request. Most granular of all three.
Who manages consistency You. In application code. Visible, debuggable, domain aware.
What you give up Automatic failover. Primary is a single point of failure. Silently stale reads during partition if replica is isolated.
When it's the right choice Single region. One primary is acceptable. You want maximum control. Your scale doesn't demand more.
Quorum (Cassandra Style)¶
Topology Leaderless. Any node accepts writes. Any node serves reads.
Write path Coordinator writes to W nodes, waits for W acks. Client gets success. Rest get it async.
Read path Coordinator reads from R nodes, returns newest value. W + R > N → guaranteed overlap → CP. W + R ≤ N → AP.
During partition
- W + R > N → partition makes writes fail if can't reach W nodes → CP
- W + R ≤ N → writes succeed on reachable nodes → AP → conflicts on heal → LWW resolution → silent data loss possible
Consistency granularity Per query type. ONE, TWO, QUORUM, LOCAL_QUORUM, ALL. Not per user session.
Who manages consistency The database. You declare consistency level. DB coordinates internally.
What you give up Per user session consistency. Write ordering guarantee. Conflict free operation.
When it's the right choice High write throughput. Multi region with LOCAL_QUORUM. Leaderless needed. Availability more important than strict ordering.
Raft¶
Topology Always one elected leader. Rest are followers. All writes go to leader.
Write path Leader receives write → sends to all followers → waits for majority ack → commits → responds to client. Sync to majority. One slow follower doesn't block.
Read path
- Linearizable → from leader, leader confirms still leader via heartbeat → CP
- Follower read → follower checks commit index → same as your LSN check
- Stale read → any follower, no check → AP opt in
During partition
- Majority side → elects leader if needed, accepts writes, CP
- Minority side → refuses writes, no leader possible → unavailable
- On heal → followers catch up from leader log → clean, no conflicts
Consistency granularity Per operation. Linearizable or stale read. Write path has no choice — always CP.
Who manages consistency The protocol itself. No app code. No proxy. No LSN logic. Mathematical guarantee.
What you give up Leaderless writes. Leader is still a write bottleneck unless sharded (CockroachDB style).
When it's the right choice Strong consistency required. Automatic failover needed. Write ordering is critical. Foundation for etcd, CockroachDB, Kubernetes.
Side By Side¶
| Your Postgres + LSN | Quorum | Raft | |
|---|---|---|---|
| Leader | Yes, manual | None | Yes, elected automatically |
| Write conflicts possible | No | Yes (AP mode) | No |
| Write ordering guaranteed | Yes | No | Yes |
| Failover | Manual via Patroni | Automatic | Automatic, mathematical |
| Read granularity | Per user session | Per query type | Per operation |
| Consistency managed by | Your code | Database | Protocol |
| Multi region | Painful | LOCAL_QUORUM | Cross region latency |
| ACID | Full (single node) | No | Yes (CockroachDB/Spanner) |
| CAP default | CP writes, AP reads | AP (ONE default) | CP |
| Conflicts on partition heal | None | LWW, silent loss possible | None |
| Real world | Your current stack | Cassandra, DynamoDB | etcd, CockroachDB, TiDB |
The One Paragraph¶
Your Postgres setup is the most granular and controllable — you make CP vs AP decisions per user per request in code you own. Quorum removes the leader, distributes writes across nodes, gives you a consistency dial per query type, but loses write ordering and risks silent data loss under AP mode. Raft brings the leader back but makes it automatic and mathematically guaranteed — strongest consistency, cleanest failure recovery, but leader is still a write bottleneck unless you shard. All three are answering the same physics problem — light speed exists, networks fail, you cannot have perfect consistency and perfect availability simultaneously. They just disagree on where to take the pain.