PACELC Theorem

Beyond CAP: The Latency Factor

The CAP theorem tells us what happens during partitions, but what about normal operation? That’s where PACELC comes in.

Simple Analogy

CAP is like asking: “What happens when the highway is closed?”
PACELC asks: “What happens when the highway is closed, AND what’s the best route when it’s open?”

The second question matters just as much!

---

What is PACELC?

PACELC extends CAP by adding latency considerations:

If there’s a Partition (P): choose between Availability and Consistency
Else (E) (normal operation): choose between Latency and Consistency

Key Insight: Even when there’s no partition, you still face a trade-off: fast responses (low latency) vs accurate data (consistency).

---

The Two Scenarios

Scenario 1: During Partition (P-A-C)

This is the CAP part we already know:

Same as CAP: During partitions, choose CP or AP.

---

Scenario 2: Normal Operation (E-L-C)

This is the new part PACELC adds:

Key Insight: Even when everything works perfectly, you still choose between speed and accuracy.

---

Understanding the E-L-C Trade-off

Low Latency → Eventual Consistency

When you prioritize low latency, you accept eventual consistency:

Example: Reading from a local cache (fast, but might be outdated) vs reading from the primary database (slower, but always accurate).

---

Strong Consistency → Higher Latency

When you prioritize consistency, you accept higher latency:

Example: Asynchronous replication (fast, but eventual) vs synchronous replication (slower, but consistent).

---

Real-World Examples

Example 1: E-Commerce Product Page

Choice: Most e-commerce sites choose low latency for product pages (cache) but consistency for checkout (database).

---

Example 2: Social Media Feed

Choice: Social media prioritizes low latency (read from nearby replica) over perfect consistency.

---

Example 3: Bank Balance Check

Choice: Banking systems prioritize consistency over latency. Users accept slower responses for accurate data.

---

The Four Combinations

PACELC gives us four possible combinations:

PA-EL: Availability + Low Latency

During partition: Choose availability
Normal operation: Choose low latency

Examples: DNS, CDN, most caching systems

Characteristics:

• Always available
• Fast responses
• May serve stale data

---

PA-EC: Availability + Consistency

During partition: Choose availability
Normal operation: Choose consistency

Examples: Cassandra (with tunable consistency), DynamoDB (with strong consistency reads)

Characteristics:

• Available during partitions
• Consistent during normal operation
• Slower during normal operation

---

PC-EL: Consistency + Low Latency

During partition: Choose consistency
Normal operation: Choose low latency

Examples: MongoDB (with strong consistency, but optimized for speed)

Characteristics:

• Consistent during partitions
• Fast during normal operation
• May reject requests during partitions

---

PC-EC: Consistency + Consistency

During partition: Choose consistency
Normal operation: Choose consistency

Examples: Traditional relational databases (PostgreSQL, MySQL)

Characteristics:

• Always consistent
• Slower (synchronous replication)
• May reject requests during partitions

---

Tuning PACELC Per Operation

Key Insight

You don’t have to choose one PACELC combination for your entire system. You can tune it per operation!

Example: An e-commerce system might:

• Product pages: PA-EL (fast, cached)
• Checkout: PC-EC (consistent, accurate)
• Inventory: PC-EC (consistent, can’t oversell)

---

LLD ↔ HLD Connection

How PACELC choices affect your method design:

Low Latency → Async Operations

When prioritizing latency, use asynchronous patterns:

💡 Tip: Click dropdown to switch between languages

Python

Python

Low Latency: Async Operations

import asyncio
from typing import Optional

class LowLatencyService:
    def __init__(self):
        self._cache = {}  # Local cache for fast reads

    async def read(self, key: str) -> Optional[object]:
        # Read from cache first (low latency)
        if key in self._cache:
            return self._cache[key]  # Fast!

        # Fallback to DB if not in cache
        return await self._read_from_db(key)

    async def write(self, key: str, value: object):
        # Write to cache immediately (low latency)
        self._cache[key] = value

        # Replicate asynchronously (eventual consistency)
        asyncio.create_task(self._replicate_async(key, value))

Java

Low Latency: Async Operations

import java.util.*;
import java.util.concurrent.*;

public class LowLatencyService {
    private Map<String, Object> cache = new ConcurrentHashMap<>();  // Local cache

    public CompletableFuture<Object> read(String key) {
        // Read from cache first (low latency)
        Object cached = cache.get(key);
        if (cached != null) {
            return CompletableFuture.completedFuture(cached);  // Fast!
        }

        // Fallback to DB if not in cache
        return readFromDb(key);
    }

    public void write(String key, Object value) {
        // Write to cache immediately (low latency)
        cache.put(key, value);

        // Replicate asynchronously (eventual consistency)
        CompletableFuture.runAsync(() -> replicateAsync(key, value));
    }
}

TypeScript

Low Latency: Async Operations

class LowLatencyService {
    private cache: Map<string, any> = new Map();  // Local cache for fast reads

    async read(key: string): Promise<any | undefined> {
        // Read from cache first (low latency)
        if (this.cache.has(key)) {
            return this.cache.get(key);  // Fast!
        }

        // Fallback to DB if not in cache
        return await this.readFromDb(key);
    }

    async write(key: string, value: any): Promise<void> {
        // Write to cache immediately (low latency)
        this.cache.set(key, value);

        // Replicate asynchronously (eventual consistency)
        this.replicateAsync(key, value).catch(err => {
            console.error('Replication failed:', err);
        });
    }

    private async readFromDb(key: string): Promise<any> {
        // Database read implementation
        return undefined;
    }

    private async replicateAsync(key: string, value: any): Promise<void> {
        // Async replication implementation
    }
}

C++

Low Latency: Async Operations

#include <unordered_map>
#include <string>
#include <future>
#include <memory>

class LowLatencyService {
private:
    std::unordered_map<std::string, std::string> cache;  // Local cache

public:
    std::future<std::string> read(const std::string& key) {
        // Read from cache first (low latency)
        auto it = cache.find(key);
        if (it != cache.end()) {
            return std::async(std::launch::deferred, [it]() {
                return it->second;  // Fast!
            });
        }

        // Fallback to DB if not in cache
        return readFromDb(key);
    }

    void write(const std::string& key, const std::string& value) {
        // Write to cache immediately (low latency)
        cache[key] = value;

        // Replicate asynchronously (eventual consistency)
        std::async(std::launch::async, [this, key, value]() {
            this->replicateAsync(key, value);
        });
    }

private:
    std::future<std::string> readFromDb(const std::string& key) {
        // Database read implementation
        return std::async(std::launch::deferred, []() {
            return std::string("");
        });
    }

    void replicateAsync(const std::string& key, const std::string& value) {
        // Async replication implementation
    }
};

C#

Low Latency: Async Operations

using System;
using System.Collections.Generic;
using System.Threading.Tasks;

public class LowLatencyService {
    private Dictionary<string, object> cache = new Dictionary<string, object>();  // Local cache

    public async Task<object> ReadAsync(string key) {
        // Read from cache first (low latency)
        if (cache.ContainsKey(key)) {
            return cache[key];  // Fast!
        }

        // Fallback to DB if not in cache
        return await ReadFromDbAsync(key);
    }

    public async Task WriteAsync(string key, object value) {
        // Write to cache immediately (low latency)
        cache[key] = value;

        // Replicate asynchronously (eventual consistency)
        _ = Task.Run(async () => {
            await ReplicateAsync(key, value);
        });
    }

    private async Task<object> ReadFromDbAsync(string key) {
        // Database read implementation
        return null;
    }

    private async Task ReplicateAsync(string key, object value) {
        // Async replication implementation
    }
}

Consistency → Sync Operations

When prioritizing consistency, use synchronous patterns:

💡 Tip: Click dropdown to switch between languages

Python

Python

Consistency: Sync Operations

from threading import Lock

class ConsistentService:
    def __init__(self):
        self._data = {}
        self._lock = Lock()
        self._replicas = []  # List of replica nodes

    def write(self, key: str, value: object) -> bool:
        with self._lock:
            # Write to primary synchronously
            self._data[key] = value

            # Replicate to all replicas synchronously (consistency)
            for replica in self._replicas:
                if not replica.set(key, value):  # Wait for each
                    return False  # Fail if any replica fails

            return True  # Only return success when all updated

Java

Consistency: Sync Operations

import java.util.*;
import java.util.concurrent.locks.ReentrantLock;

public class ConsistentService {
    private Map<String, Object> data = new HashMap<>();
    private final ReentrantLock lock = new ReentrantLock();
    private List<Replica> replicas = new ArrayList<>();

    public boolean write(String key, Object value) {
        lock.lock();
        try {
            // Write to primary synchronously
            data.put(key, value);

            // Replicate to all replicas synchronously (consistency)
            for (Replica replica : replicas) {
                if (!replica.set(key, value)) {  // Wait for each
                    return false;  // Fail if any replica fails
                }
            }

            return true;  // Only return success when all updated
        } finally {
            lock.unlock();
        }
    }
}

TypeScript

Consistency: Sync Operations

interface Replica {
    set(key: string, value: any): boolean;
}

class ConsistentService {
    private data: Map<string, any> = new Map();
    private lock: boolean = false;
    private replicas: Replica[] = [];

    write(key: string, value: any): boolean {
        // Simple lock simulation (in real code, use proper locking)
        if (this.lock) {
            return false;  // Locked
        }
        this.lock = true;

        try {
            // Write to primary synchronously
            this.data.set(key, value);

            // Replicate to all replicas synchronously (consistency)
            for (const replica of this.replicas) {
                if (!replica.set(key, value)) {  // Wait for each
                    return false;  // Fail if any replica fails
                }
            }

            return true;  // Only return success when all updated
        } finally {
            this.lock = false;
        }
    }
}

C++

Consistency: Sync Operations

#include <unordered_map>
#include <vector>
#include <mutex>
#include <memory>

class Replica {
public:
    virtual bool set(const std::string& key, const std::string& value) = 0;
};

class ConsistentService {
private:
    std::unordered_map<std::string, std::string> data;
    std::mutex lock;
    std::vector<std::shared_ptr<Replica>> replicas;

public:
    bool write(const std::string& key, const std::string& value) {
        std::lock_guard<std::mutex> guard(lock);

        // Write to primary synchronously
        data[key] = value;

        // Replicate to all replicas synchronously (consistency)
        for (const auto& replica : replicas) {
            if (!replica->set(key, value)) {  // Wait for each
                return false;  // Fail if any replica fails
            }
        }

        return true;  // Only return success when all updated
    }
};

C#

Consistency: Sync Operations

using System;
using System.Collections.Generic;
using System.Threading;

public interface IReplica {
    bool Set(string key, string value);
}

public class ConsistentService {
    private Dictionary<string, object> data = new Dictionary<string, object>();
    private readonly object lockObject = new object();
    private List<IReplica> replicas = new List<IReplica>();

    public bool Write(string key, object value) {
        lock (lockObject) {
            // Write to primary synchronously
            data[key] = value;

            // Replicate to all replicas synchronously (consistency)
            foreach (var replica in replicas) {
                if (!replica.Set(key, value.ToString())) {  // Wait for each
                    return false;  // Fail if any replica fails
                }
            }

            return true;  // Only return success when all updated
        }
    }
}

---

Decision Framework

Use this framework to choose your PACELC combination:

Use Case	PACELC Choice	Why
Bank balance	PC-EC	Accuracy > Speed
Product page	PA-EL	Speed > Perfect accuracy
Checkout	PC-EC	Accuracy > Speed
Social feed	PA-EL	Speed > Perfect accuracy
Inventory	PC-EC	Accuracy > Speed (can’t oversell)

---

Key Takeaways

Remember

• PACELC extends CAP by adding latency considerations
• P-A-C: During partitions, choose Availability or Consistency (same as CAP)
• E-L-C: During normal operation, choose Latency or Consistency (new!)
• Four combinations: PA-EL, PA-EC, PC-EL, PC-EC
• Tune per operation: Different operations can use different PACELC choices
• LLD impact: Low latency → async patterns, Consistency → sync patterns
• Choose based on use case: Critical data = consistency, User experience = latency

---

What’s Next?

Now that you understand consistency trade-offs, let’s explore how to maintain consistency across multiple operations:

Next up: Distributed Transactions — Learn how to coordinate multiple operations across distributed systems using 2PC, Saga pattern, and compensation.

Practice Exercise

Think about an API endpoint you’ve designed. What PACELC combination does it use? Could you optimize it by choosing a different combination? What would break?