CAP and PACELC: The Trade-off You're Making Whether You Name It or Not
Eric Brewer's CAP theorem gets taught as a pick-two puzzle — Consistency, Availability, Partition tolerance, choose any two — and that framing has confused more engineers than it's helped, because it implies partition tolerance is optional. It isn't. In any distributed system, across multiple machines, over a real network, partitions are going to happen: a link drops, a node gets slow enough to look dead, a data center has a bad day. The actual theorem says something narrower and more useful: when a partition happens, you must choose between consistency and availability for the duration of that partition. You don't get to skip the choice by being careful.
What you're actually deciding
If you choose consistency, your system refuses to answer (or blocks) rather than risk returning stale or conflicting data while nodes can't agree — correctness over uptime. If you choose availability, every node keeps answering requests using whatever data it locally has, even if it might be out of date or diverge from another node's answer — uptime over correctness. Neither choice is wrong. They're right for different systems, and the mistake isn't picking one, it's not realizing you've picked one at all, which is what happens by default whenever a team adopts a database without asking which side of this line it falls on.
PACELC finishes the sentence CAP starts
CAP only describes behavior during a partition, which is a relatively small fraction of a distributed system's operating life. Daniel Abadi's PACELC extension asks the more useful everyday question: else, when there's no partition and everything's healthy, what do you trade off? His answer is latency against consistency — a system that wants strong consistency has to coordinate across replicas before confirming a write, which costs time, while a system willing to accept eventual consistency can respond as soon as one node has the data, which is fast. This is the trade-off your system is making on every single request, partition or not, and it's the one I find teams have thought about even less than the CAP choice, because it doesn't announce itself with an outage — it just shows up as a p99 latency number nobody questioned.
Where this shows up in AI infrastructure specifically
Every AI system I've worked on has at least three places where this decision is live, usually made implicitly by whatever the default configuration of the chosen database happened to be. Your vector database is the clearest case: most are tuned toward availability and low latency by default, returning approximate nearest-neighbor results from whichever replica answers fastest, which is exactly right for search-style retrieval where a slightly stale index is harmless — but is the wrong default if that same store is also holding anything that needs to be authoritative, like access-control metadata that gates what a retrieval-augmented system is allowed to show a given user. Your feature store or session state has the opposite pull: an agent's short-term memory or a user's in-progress conversation state usually needs consistency, because serving a stale version of "what did I just tell you" breaks the interaction in a way that's immediately visible to the user, not just a data-quality footnote. And your evaluation and decision-logging store — the one I've argued needs to exist as a first-class data model — needs to lean toward consistency and durability over raw latency, because the entire point of that store is being trustworthy evidence later, not being fast now.
The failure mode I actually see isn't picking wrong. It's not picking — inheriting whatever a database's defaults happen to be for three or four different subsystems with genuinely different requirements, and finding out which one you got only when a partition happens or a latency graph looks strange, months after the system's been in production. A five-minute conversation at design time — "does this specific data store need to favor correctness or uptime, and are we okay with the latency cost either way" — is cheap. Discovering the answer during an incident is not.
This is a per-subsystem decision, not a per-system one
The temptation is to treat CAP/PACELC as a single decision for "the architecture," the way people sometimes treat SQL-versus-NoSQL as one global choice. It isn't, any more than the Technical Debt Quadrant produces one verdict for an entire codebase. A single AI system typically has a retrieval layer, a session/state layer, and an audit layer, and each one has a legitimately different right answer on this trade-off. The job isn't to pick a philosophy and apply it everywhere — it's to look at each data store your system depends on and ask, deliberately, which side of the line it needs to be on, instead of finding out by accident whichever way the default pointed.