Prerequisites

The Gap CAP Leaves

CAP describes what happens during a network partition. That is a genuine constraint, but partitions are infrequent. A well-run system may spend almost all of its operating life with a perfectly healthy network.

This creates an awkward situation. CAP governs a rare condition, yet architects use it to justify decisions that affect every request, every day, whether or not anything has failed.

The PACELC Formulation

PACELC extends CAP by adding the normal-operation case. It reads as a conditional statement with two branches.

Why Consistency Costs Latency

A linearizable write cannot be acknowledged until enough replicas have durably recorded it. The acknowledgement therefore cannot arrive before the slowest required replica has replied.

Here \(Q\) is the set of replicas forming the write quorum. The write is bounded below by the round trip to the furthest member, which is a property of physics rather than implementation quality.

The Four Classifications

Combining both branches yields four categories. Each describes a coherent design posture.

Topology Determines Classification

A system's PACELC position is largely a consequence of how it replicates, not an independent choice layered on afterwards.

Tunable Systems and Per-Operation Position

Many datastores expose consistency as a request-level parameter. This means the classification is not fixed for the system but selected per operation.

const OPERATION_PROFILE = {
    "order.create": {
        writeConsistency: "quorum",
        readConsistency:  "quorum",
        pacelc: "PC/EC",
        rationale: "duplicate or lost orders are unacceptable"
    },
    "inventory.reserve": {
        writeConsistency: "quorum",
        readConsistency:  "quorum",
        pacelc: "PC/EC",
        rationale: "overselling has direct financial cost"
    },
    "profile.read": {
        writeConsistency: "quorum",
        readConsistency:  "local",
        pacelc: "PC/EL",
        rationale: "durable writes, fast reads, brief staleness tolerable"
    },
    "activity.record": {
        writeConsistency: "one",
        readConsistency:  "local",
        pacelc: "PA/EL",
        rationale: "volume is high and individual loss is immaterial"
    }
};

async function execute(operationName, payload) {
    const profile = OPERATION_PROFILE[operationName];

    if (!profile) {
        throw new Error(
            `Operation ${operationName} has no declared consistency profile`
        );
    }

    return await datastore.execute(payload, {
        writeConsistency: profile.writeConsistency,
        readConsistency:  profile.readConsistency
    });
}

Intermediate Consistency Levels

The else-branch is not a binary between linearizable and eventual. Several intermediate guarantees provide useful properties at lower cost.

async function readWithSessionGuarantee(key, session) {
    const lastWriteVersion = session.versions.get(key);

    if (!lastWriteVersion) {
        return await datastore.readLocal(key);
    }

    const localValue = await datastore.readLocal(key);

    if (localValue.version >= lastWriteVersion) {
        return localValue;
    }

    return await datastore.readQuorum(key);
}

This pattern serves the fast local read in the common case and escalates to a coordinated read only when the local replica has not yet caught up with the client's own write.

Quantifying the Choice

The else-branch decision becomes concrete once you estimate what coordination costs in your specific deployment.

function estimateConsistencyCost(topology) {
    const localReadMs = topology.localReadMs;

    const quorumMembers = topology.replicaLatenciesMs
        .slice()
        .sort((a, b) => a - b)
        .slice(0, topology.quorumSize);

    const slowestInQuorum = quorumMembers[quorumMembers.length - 1];

    const consistentReadMs = slowestInQuorum + topology.processingMs;

    return {
        localReadMs: localReadMs,
        consistentReadMs: consistentReadMs,
        additionalMs: consistentReadMs - localReadMs,
        multiplier: (consistentReadMs / localReadMs).toFixed(1)
    };
}

Latency Compounds Across Services

A single coordinated read may seem affordable in isolation. In a request that traverses several services, each consistency decision adds to a total the user experiences as one number.

A Worked Example

Consider a globally deployed commerce platform and how each operation lands within PACELC.

Disclosing the Choice

When the else-branch favours latency, clients receive data of unknown freshness. Stating which level was applied allows callers to make informed decisions.

{
    "data": {
        "productId": "product-501",
        "price": 2499.00,
        "available": true
    },
    "consistency": {
        "branch": "else",
        "levelApplied": "local-read",
        "pacelcPosition": "PA/EL",
        "replicaAsOf": "2026-09-24T05:20:14Z",
        "estimatedStalenessMs": 340,
        "upgradeAvailable": true
    }
}

Observing Both Branches

Common Design Mistakes

System Design Interview Discussion

Design Checklist

Knowledge Check

Summary

PACELC extends CAP by acknowledging that the consistency trade-off does not disappear when the network is healthy. If a partition occurs, the system trades availability against consistency; else, it trades latency against consistency.

The else-branch is the more consequential half in practice, because partitions are rare while every request pays coordination cost. That cost has a physical floor set by the round trip to the slowest replica in the quorum, which distance alone can make prohibitive.

The four classifications follow largely from replication topology. Consensus replication tends toward PC/EC, asynchronous and leaderless models toward PA/EL, and tunable stores let the position be selected per request rather than fixed.

The decision is not binary. Bounded staleness, read-your-writes, and monotonic reads occupy useful middle ground, frequently removing the anomalies users would notice at a small fraction of the cost of full linearizability.