Linearizability sounds like the perfect consistency model—it makes distributed systems behave like a single machine. So why doesn't every system use it?

The answer lies in the costs. Achieving linearizability requires coordination among distributed nodes, and coordination is expensive. Every read and write operation must be validated against the global state, ensuring no concurrent operation has changed the data. This coordination introduces latency, limits throughput, and creates availability trade-offs that many systems cannot accept.

Understanding these costs is essential for making informed architectural decisions. Some systems genuinely require linearizability and must pay the price. Others can achieve their goals with weaker consistency models at a fraction of the cost. The art of distributed systems design lies in knowing which is which.

Linearizability requires nodes to agree on the order of operations. This agreement—called consensus—is inherently expensive because it requires communication between multiple nodes before any operation can complete.

The Cost of Consensus

Consensus protocols like Raft and Paxos provide linearizability but introduce significant overhead:

1. Round-Trip Requirements

A typical Raft write requires:

• Client → Leader: 1 message
• Leader → Followers: N-1 messages
• Followers → Leader: N-1 acknowledgments (wait for majority)
• Leader → Client: 1 message

For a 5-node cluster, this is at minimum 2 round-trips before the client gets a response. Each round-trip adds network latency.

2. Serialization at the Leader

In leader-based protocols, all operations must flow through the leader. This creates:

• Throughput bottleneck: Leader CPU becomes the limiting factor
• Head-of-line blocking: One slow operation delays all subsequent operations
• Increased latency variance: Queuing at the leader adds unpredictable delays

3. Disk I/O on the Critical Path

Most consensus protocols require durable writes before acknowledging:

time = network_rtt + disk_fsync + processing

Each follower must write the log entry to disk before responding. This ensures operations survive crashes but adds 0.5-10ms per operation depending on storage.

4. Quorum Waiting

Operations block until a quorum (typically majority) responds. The latency is determined by the slowest member of the fastest quorum:

Let's perform a detailed latency analysis for a linearizable operation in a real-world distributed system.

Components of Linearizable Write Latency

For a Raft-based system with 5 nodes in a single region:

Multi-Region Scenario

Now consider the same operation with global distribution (replicas in US-East, US-West, Europe):

Minimum physical latencies:

• US-East to US-West: ~60ms RTT
• US-East to Europe: ~80ms RTT
• US-West to Europe: ~140ms RTT

With a 5-node cluster (2 US-East, 2 US-West, 1 Europe), a write from US-East must wait for at least one US-West acknowledgment:

Linearizable Read Latency

Reads in a linearizable system are also expensive. There are several strategies:

Option 1: Route reads through consensus (safest)

• Same latency as writes (~70ms multi-region)
• Guarantees you see the latest committed value
• Often impractical due to performance

Option 2: Leader leases (optimized)

• Leader holds a time-limited lease
• Reads served locally while lease is valid
• Latency: ~1-2ms (local read)
• Risk: Clock skew can violate linearizability

Option 3: Read-after-write (hybrid)

• Reads wait until their causal dependency is committed
• Latency varies based on concurrent writes

Beyond latency, linearizability limits throughput in ways that can surprise engineers accustomed to eventually consistent systems.

The Single-Leader Bottleneck

In leader-based consensus:

Max throughput = 1 / (consensus_latency + processing_time)

If consensus takes 70ms and processing takes 1ms:

• Maximum: ~14 operations/second per consensus group
• With batching: Maybe 1,000-2,000 ops/second

Compare to an eventually consistent system:

• Each replica can accept writes independently
• 5 replicas × 10,000 ops/second = 50,000 ops/second
• Eventually converge asynchronously

Batching and Pipelining

Real systems use several techniques to improve throughput:

1. Log Batching Group multiple operations into a single consensus round:

// Instead of:
consensus(op1)  // 70ms
consensus(op2)  // 70ms  
consensus(op3)  // 70ms
// Total: 210ms for 3 ops

// Batching:
consensus([op1, op2, op3])  // 70ms
// Total: 70ms for 3 ops

2. Pipelining Start new consensus rounds before previous ones complete:

T=0ms:   propose(batch1)
T=10ms:  propose(batch2)
T=20ms:  propose(batch3)
T=70ms:  batch1 committed
T=80ms:  batch2 committed
...

This increases throughput but doesn't reduce individual operation latency.

Partitioning for Scale

The only way to scale linearizable write throughput is to partition the data:

• Each partition has its own consensus group
• Operations on different partitions are independent
• Cross-partition operations require expensive protocols (2PC, Saga)

Total throughput = partitions × throughput_per_partition

// With 100 partitions:
100 × 1,000 ops/sec = 100,000 ops/sec

// But cross-partition operations are 10x more expensive

This is how systems like CockroachDB and Spanner achieve reasonable throughput while maintaining linearizability—by sharding data into many independent Raft groups.

The CAP theorem states that during a network partition, a distributed system must choose between Consistency and Availability. Linearizable systems choose consistency—meaning they become unavailable when partitions occur.

What Happens During Partitions

Consider a 5-node Raft cluster that gets split by a network partition:

Scenario: 3-2 Split

[Node A, Node B, Node C]  |  [Node D, Node E]
       (majority)         |     (minority)

• Majority partition: Can form quorum, continues operating
• Minority partition: Cannot form quorum, must reject all writes

Clients connected to the minority partition experience complete unavailability for writes until the partition heals.

Scenario: 2-2-1 Split

[Node A, Node B]  |  [Node C, Node D]  |  [Node E]

• No partition has a majority
• Entire system becomes unavailable
• All clients experience outage

Availability Calculations

Let's compute availability for a linearizable system:

Single-node failure tolerance (5 nodes)

• Can tolerate 2 node failures
• Availability = 1 - P(3+ failures)

If each node has 99.9% availability (8.76 hours downtime/year):

P(single node down)    = 0.001
P(3+ down)             = C(5,3) × 0.001³ + C(5,4) × 0.001⁴ + C(5,5) × 0.001⁵
                       ≈ 10 × 10⁻⁹
Cluster availability   ≈ 99.999999%

But this ignores network partitions!

Network partitions are more frequent than node failures:

• Major cloud providers: 1-10 significant partitions/year
• Each might last minutes to hours
• Minority partitions: clients in minority are unavailable

Realistic availability accounting for partitions: 99.9% to 99.99%, not "five nines."

Leader Election Delays

Even without partitions, leader failures cause availability gaps:

Leader dies
  → Detection timeout: 1-10 seconds (heartbeat intervals)
  → Election: 1-5 seconds (depending on protocol)
  → New leader stabilizes: 0.5-2 seconds
  
Total unavailability: 2-17 seconds per leader failure

In a 5-node cluster with aggressive timeouts:

• Leader elections might occur 10-50 times/year
• Each causes 2-5 seconds of write unavailability
• Total: 20-250 seconds/year of outage from elections alone

This doesn't count partial availability during the instability period when requests timeout or are rejected.

Beyond the algorithmic costs, linearizable systems require significant infrastructure investment and operational expertise.

Hardware Requirements

1. Low-Latency Networking

• Consensus is latency-sensitive
• Need high-bandwidth, low-jitter networks
• Consider dedicated interconnects within regions
• RDMA or InfiniBand for extreme performance

2. High-Performance Storage

• SSDs or persistent memory required
• fsync latency directly impacts consensus
• Consider battery-backed write cache
• Plan for storage failover

3. Clock Synchronization

• Some protocols require bounded clock skew
• NTP may not be sufficient (100ms+ drift possible)
• Consider PTP (Precision Time Protocol): μs accuracy
• Spanner uses GPS + atomic clocks: ns accuracy

4. Odd Number of Nodes

• Quorum = (N/2) + 1
• Example: 4 nodes still only tolerates 1 failure
• Example: 5 nodes tolerates 2 failures
• 5 nodes preferred over 4 for same budget

Operational Complexity

1. Monitoring and Alerting

Linearizable systems require vigilant monitoring:

Critical metrics to track:
- Replication lag per follower
- Leader election events
- Quorum health (nodes reachable)
- Consensus round latency (P50, P99, P99.9)
- Disk sync latency
- Write queue depth
- Client timeout rates

2. Failure Testing

Regular failure testing is essential:

• Simulate leader failures
• Induce network partitions
• Test clock skew scenarios
• Verify behavior during rolling upgrades

3. Upgrade Complexity

Rolling upgrades require careful orchestration:

• Cannot take down a quorum simultaneously
• Leader step-down before upgrade
• Verify replication health between each node
• Rollback plan if issues arise

Let's quantify the costs of linearizability compared to alternative consistency models:

Scenario: Global User Profile Service

Requirements:

• 100 million users
• 50,000 reads/second
• 5,000 writes/second
• 99.99% availability target
• Global distribution (US, Europe, Asia)

When the Cost Is Justified

Linearizability's costs are justified when:

1. Coordination correctness is critical: Lock services, leader election, unique constraints
2. Financial transactions: Cannot afford lost or duplicate transactions
3. Strong consistency is a product requirement: Users expect real-time accuracy
4. The workload is naturally low-volume: Configuration management, metadata
5. Cross-region latency is acceptable: Batch processing, non-interactive systems

When the Cost Is Not Justified

Linearizability is overkill for:

1. Social media feeds: Eventual consistency with read-your-writes is sufficient
2. Analytics and reporting: Data is already timestamped; stale reads acceptable
3. Session storage: Session affinity provides effective consistency
4. Caching layers: Eventual consistency with TTL is the norm
5. Event logging: Append-only, naturally ordered by time

We've performed a detailed analysis of what it costs to implement linearizability. These costs are inherent, not accidental—they stem from the fundamental requirements of distributed coordination.

What's Next:

Understanding the costs, we'll now explore the performance implications in more depth—specifically, how latency affects user experience and throughput affects business operations, and what optimization strategies exist.