Patterns

35 items

System Design Pattern

Consistencystrong-consistencylinearizabilityconsensuscorrectnesscoordinationadvanced

Strong Consistency Pattern

Linearizable operations for correctness guarantees

Used in: Banking, Inventory, Reservations|30 min read

Summary

Strong Consistency (Linearizability) guarantees that all operations appear to occur atomically and in total order. Once a write completes, all subsequent reads see that write. This provides the strongest correctness guarantee but comes at significant cost: lower availability during partitions, higher latency, and limited scalability. Essential for financial transactions and inventory management.

Key Takeaways

Linearizability: The Gold Standard

Linearizability means operations appear to occur instantaneously at some point between invocation and response. Once a write completes, all reads see that value or newer—never older.

CAP Theorem: Choosing CP over AP

Strong consistency requires choosing Consistency and Partition tolerance (CP). During partitions, the system sacrifices availability—nodes that cannot communicate with majority must refuse operations.

Consensus Protocols: Raft and Paxos

Achieving strong consistency requires consensus protocols like Raft or Paxos. These ensure all nodes agree on operation order, even during failures. They work by having a leader coordinate writes with majority acknowledgment.

Eventual consistency introduces complexity. Applications must handle stale reads, conflicting writes, and non-linearizable behavior. Strong consistency eliminates these concerns by guaranteeing all operations see consistent state.

Raft Consensus Protocol

Summary

Key Takeaways

Linearizability: The Gold Standard

Linearizability means operations appear to occur instantaneously at some point between invocation and response. Once a write completes, all reads see that value or newer—never older.

CAP Theorem: Choosing CP over AP

Consensus Protocols: Raft and Paxos

Quorum Reads and Writes

Strong consistency often uses quorum-based replication: write to majority (W > N/2) and read from majority (R > N/2) where R + W > N. This ensures reads overlap with latest write.

Two-Phase Commit for Distributed Transactions

Strong consistency across multiple resources requires distributed transactions via Two-Phase Commit (2PC). 2PC has high latency and coordinator is single point of failure.

When Strong Consistency is Non-Negotiable

Some domains cannot tolerate inconsistency: financial transactions, inventory management, seat reservations, and distributed locking. For these, strong consistency is mandatory despite costs.

Pattern Details

Raft Consensus Protocol

Trade-offs

Aspect	Advantage	Disadvantage

Patterns

Horizontal Scaling Pattern

Retry with Backoff Pattern

Replication Pattern

Caching Strategies Pattern

Persistent Connections Pattern

Load Balancing Pattern

Fan-out Pattern

Fan-in Pattern

Circuit Breaker Pattern

Eventual Consistency Pattern

Queue-based Load Leveling Pattern

Bloom Filters Pattern

Time-Series Storage Pattern

Bulkhead Pattern

Batch Processing Pattern

Write-Ahead Log Pattern

API Gateway Pattern

Backend for Frontend Pattern

Sidecar Pattern

Idempotency Pattern

Rate Limiting Pattern

Backpressure Pattern

Pub/Sub Pattern