CAP & cohérence à terme, ou le théorème qui force à choisirCAP & eventual consistency, or the theorem that forces a choice

Cohérent, disponible, tolérant à la partition. Le réseau coupera — il faudra en sacrifier un.Consistent, available, partition-tolerant. The network will cut — you'll sacrifice one.

Le sharding du numéro précédent distribue la donnée pour la capacité ; pour survivre à la panne d'une machine, on réplique chaque morceau sur plusieurs nœuds. Et dès qu'une donnée existe en plusieurs exemplaires, une question devient inévitable : que se passe-t-il quand le réseau coupe entre ces copies ? Le théorème CAP y répond, et sa réponse est un mur. Il énonce qu'un système distribué ne peut garantir simultanément que trois propriétés : la cohérence (toute lecture voit la dernière écriture), la disponibilité (toute requête reçoit une réponse), et la tolérance à la partition (le système continue malgré une coupure réseau). On résume souvent par « choisis-en deux » — mais c'est un raccourci trompeur. Car la partition n'est pas une option qu'on accepte ou refuse : sur un vrai réseau, elle finit toujours par arriver, exactement comme le Vol 7 l'a martelé — le réseau n'est pas fiable. Le vrai énoncé est donc plus dur : quand une partition survient — et elle surviendra —, il faut choisir entre rester cohérent et rester disponible. On ne peut pas avoir les deux pendant la coupure. Le réflexe n'est pas « notre base est cohérente ET disponible » : c'est « quand le réseau cassera, ce système préfère-t-il refuser de répondre, ou répondre peut-être faux ? »The previous issue's sharding distributes data for capacity; to survive one machine's failure, you replicate each piece across several nodes. And once data exists in several copies, a question becomes inescapable: what happens when the network cuts between those copies? The CAP theorem answers, and its answer is a wall. It states that a distributed system cannot simultaneously guarantee three properties: consistency (every read sees the latest write), availability (every request gets a response), and partition tolerance (the system keeps working despite a network cut). It's often summed up as 'pick two' — but that's a misleading shortcut. Because the partition isn't an option you accept or refuse: on a real network, it always ends up happening, exactly as Vol 7 hammered — the network isn't reliable. So the true statement is harder: when a partition occurs — and it will — you must choose between staying consistent and staying available. You can't have both during the cut. The reflex isn't 'our database is consistent AND available': it's 'when the network breaks, does this system prefer to refuse to answer, or to answer maybe-wrong?'

# deux réplicas pour survivre à une panne. on écrit, on lit, "et c'est cohérent". vraiment ?
def write(key, value):
    primary.put(key, value)
    replica.put(key, value)        # 💥 et si le réseau coupe ICI ? le réplica ne reçoit jamais l'écriture
    return "ok"                    #    on renvoie "ok" — mais les deux copies divergent déjà

def read(key):
    return nearest_node().get(key) # 💥 on lit le nœud le plus proche — qui peut détenir l'ANCIENNE valeur
# tant que le réseau tient, tout va bien. le jour où il coupe — et il coupera —, il faut un CHOIX :
# refuser de répondre pour rester cohérent, ou répondre une valeur peut-être périmée pour rester dispo.
# ce code ne choisit pas. il fait semblant que la partition n'arrive jamais. c'est le seul vrai bug.

On croit avoir « CA ». On découvre, le jour de la coupure, qu'on n'a rien choisi.You think you have 'CA'. You discover, the day of the cut, that you chose nothing.

Ignorer CAP a trois coûts, et aucun ne se voit tant que le réseau tient — tous arrivent le jour de la première coupure. D'abord, on a cru à un système « CA » : cohérent et toujours disponible, parce qu'on ne l'a jamais vu sous partition. C'est une illusion entretenue par la chance ; le jour où le lien casse, le système choisit à notre place, et rarement comme on l'aurait voulu. Ensuite, le choix par défaut frappe au pire moment : une base configurée par habitude refuse soudain les écritures en pleine panne (indisponibilité subie), ou bien continue d'accepter des deux côtés et laisse les copies diverger (incohérence subie) — sans qu'aucune décision consciente ait été prise. Enfin, la réconciliation arrive sans plan : quand la partition se referme, deux versions de la vérité se font face, et faute d'avoir prévu comment les fusionner, on perd des écritures ou on fige des conflits. Trois douleurs qui partagent une racine : avoir traité une loi du distribué comme un détail d'infrastructure.Ignoring CAP has three costs, and none shows as long as the network holds — all arrive the day of the first cut. First, you believed in a 'CA' system: consistent and always available, because you never saw it under partition. It's an illusion sustained by luck; the day the link breaks, the system chooses for you, and rarely as you'd have wanted. Then, the default choice strikes at the worst moment: a database configured by habit suddenly refuses writes mid-outage (unavailability endured), or keeps accepting on both sides and lets the copies diverge (inconsistency endured) — without any conscious decision being made. Finally, reconciliation arrives with no plan: when the partition heals, two versions of the truth face each other, and for lack of having planned how to merge them, you lose writes or freeze conflicts. Three pains sharing one root: having treated a law of the distributed as an infrastructure detail.

# 10h00 : réseau OK. on écrit "stock = 1" sur les deux réplicas. tout est cohérent.
# 10h05 : le lien entre datacenters CASSE. deux îlots qui ne se voient plus.

# côté A, un client achète le dernier exemplaire :
node_a.put("stock", 0)        # 💥 node_a passe à 0, mais ne peut pas prévenir node_b

# côté B, AU MÊME instant, un autre client achète "le dernier exemplaire" :
node_b.read("stock")          # 💥 renvoie 1 (la valeur d'avant la coupure) → vente acceptée
node_b.put("stock", 0)        #    on a vendu DEUX fois un stock de un. aucun n'a vu l'autre.

# 10h20 : le lien revient. node_a dit stock=0, node_b dit stock=0… mais deux commandes existent.
# sans réconciliation prévue, le conflit est déjà en production — et personne ne l'a décidé.

Sain, coupé, CP, AP, réconcilié — sous partition, cohérent ou disponible, jamais les deux.Healthy, cut, CP, AP, reconciled — under partition, consistent or available, never both.

CAP ne se comprend pas comme un slogan « choisis-en deux », mais comme une bifurcation au moment de la coupure. L'animation suit deux réplicas d'une même donnée à travers cinq instants : le réseau sain où ils s'accordent, la partition qui les isole, puis les deux seules conduites possibles — CP, où un côté refuse pour rester juste, et AP, où les deux répondent au prix de la divergence —, et enfin le retour du lien, où la cohérence à terme réconcilie. Surveille la valeur de chaque nœud, le lien entre eux, et l'étiquette C / A / P : c'est l'instant de la coupure qui révèle ce que le système a vraiment choisi.CAP isn't understood as a 'pick two' slogan, but as a fork at the moment of the cut. The animation follows two replicas of the same data through five instants: the healthy network where they agree, the partition that isolates them, then the only two possible conducts — CP, where one side refuses to stay correct, and AP, where both answer at the price of divergence —, and finally the link's return, where eventual consistency reconciles. Watch each node's value, the link between them, and the C / A / P label: it's the moment of the cut that reveals what the system truly chose.

# le choix CAP n'est pas global : il se règle par opération, via le niveau de cohérence.
def write_balance(key, value, version):▸ à toiyour turn — solde bancaire : une réponse fausse coûte de l'argent — quel niveau de cohérence, quitte à refuser sous partition ?bank balance: a wrong answer costs money — which consistency level, even if it refuses under partition? · cliquer pour révélerclick to reveal    # lectures en QUORUM aussi (R + W > N) : le côté minoritaire refuse → cohérent, mais indisponible.

def write_like(post_id):▸ à toiyour turn — compteur de likes : un décalage est invisible — quel niveau de cohérence pour répondre toujours ?like counter: a lag is invisible — which consistency level to always answer? · cliquer pour révélerclick to reveal    # sous partition, chaque côté accepte → disponible, mais divergent. (like = on choisit A)

def reconcile(versions):                      # la cohérence à terme a TOUJOURS besoin d'un plan▸ à toiyour turn — les versions ont divergé pendant la coupure — que renvoie-t-on pour qu'elles convergent à la reprise ?the versions diverged during the cut — what do you return so they converge on recovery? · cliquer pour révélerclick to reveal    # un profil tolérerait last-write-wins ; un compteur, non — LWW y perdrait des likes.
# règle : on ne choisit pas C-ou-A "pour le système", on le choisit par donnée, sur le coût de la faute.

Croire qu'on a « CA », ou choisir AP sans plan de réconciliation.Believing you have 'CA', or choosing AP with no reconciliation plan.

Deux dérives encadrent le bon usage de CAP. La première nie le théorème : on suppose un réseau parfait, on ne configure aucun niveau de cohérence, et l'on croit tenir un système à la fois cohérent et toujours disponible. Le « CA » n'existe pas dans le distribué ; le jour de la coupure, le comportement par défaut tranche à ta place, et souvent dans le mauvais sens. La seconde sur-applique la disponibilité : on choisit AP « parce qu'on veut que ça réponde toujours », mais sans prévoir comment les versions divergentes se rejoindront. Or un AP sans réconciliation n'est pas disponible — il perd des écritures en silence : le last-write-wins par défaut écrase une des deux vérités sans prévenir personne. La première dérive ne choisit pas ; la seconde choisit la moitié d'une stratégie. Bascule le toggle : repère le système qui croit échapper à CAP, et celui qui réclame la disponibilité sans en payer le prix — la convergence.Two drifts frame correct use of CAP. The first denies the theorem: you assume a perfect network, configure no consistency level, and believe you hold a system both consistent and always available. 'CA' doesn't exist in the distributed; the day of the cut, the default behavior settles for you, often the wrong way. The second over-applies availability: you choose AP 'because you want it to always answer', but without planning how the divergent versions will rejoin. Yet an AP with no reconciliation isn't available — it loses writes silently: the default last-write-wins overwrites one of the two truths without telling anyone. The first drift doesn't choose; the second chooses half a strategy. Flip the toggle: spot the system that thinks it escapes CAP, and the one that demands availability without paying its price — convergence.

# on choisit C-ou-A PAR DONNÉE, sur le coût de la faute — pas une fois pour tout le système.
# solde bancaire : une réponse fausse coûte de l'argent → CP. on préfère indisponible que faux.
def debit(account, amount):
    return db.transaction(account, amount, consistency=QUORUM)   # ✓ majorité requise, sinon échec net
    # lecture ET écriture en quorum (R + W > N), débit conditionnel au solde lu (CAS) :
    # sous partition, le côté minoritaire refuse → on ne débite jamais deux fois. (on choisit C)

# compteur de vues : un décalage de 3 s est invisible, l'indisponibilité serait coûteuse → AP.
def increment_views(post_id):
    db.put(post_id, +1, consistency=ONE)                         # ✓ un réplica suffit, on répond toujours

def reconcile_views(versions):                                   # ✓ convergence PRÉVUE d'avance
    return sum(v.delta for v in versions)        # somme commutative → pas de perte au rapprochement
# règle : P est imposé. on décide C ou A là où ça compte, et on conçoit la réconciliation AVANT la coupure.

Cohérent, ou disponible — et l'architecte est celui qui sait, ici, lequel sacrifier.Consistent, or available — and the architect is the one who knows, here, which to sacrifice.

Quand la question CAP ne se pose pasWhen the CAP question doesn't arise

CAP ne s'invite que là où une donnée vit en plusieurs exemplaires séparables par le réseau. On n'a pas à trancher C-ou-A — et c'est tant mieux — quand :CAP only invites itself where data lives in several copies separable by the network. You don't have to settle C-or-A — and so much the better — when:

• la donnée tient sur un seul nœud non répliqué : pas de copies, pas de partition possible entre elles, pas de dilemme. C'est le cas par défaut, et le plus simple — on n'entre dans CAP qu'en distribuant, et on ne distribue qu'avec un chiffre (le #1 et le #2 de ce volume).the data fits on a single un-replicated node: no copies, no partition possible between them, no dilemma. It's the default case, and the simplest — you enter CAP only by distributing, and you distribute only with a number (this volume's #1 and #2).
• la cohérence forte est offerte et suffisante : à petite échelle, une base unique transactionnelle donne C et A tant que la machine tient. Tant qu'on n'a pas besoin de plusieurs nœuds, réclamer une architecture « CAP-aware » est de l'optimisation prématurée — précisément ce que ce dernier volume refuse.strong consistency is given and sufficient: at small scale, a single transactional database gives C and A as long as the machine holds. Until you need several nodes, demanding a 'CAP-aware' architecture is premature optimization — precisely what this final volume refuses.
• l'incohérence est sans conséquence ET la convergence est commutative : compteurs, télémétrie, signaux idempotents qui fusionnent sans perte. Là, AP est un choix par défaut tranquille, parce que la réconciliation est triviale — on prend la disponibilité sans rien risquer.inconsistency is inconsequential AND convergence is commutative: counters, telemetry, idempotent signals that merge without loss. There, AP is a calm default, because reconciliation is trivial — you take availability risking nothing.

Le réflexe n'est donc pas « notre système est CP » ou « notre système est AP », comme une étiquette posée une fois : c'est « cette donnée-ci, quand le réseau coupera, je veux qu'elle refuse plutôt que de mentir — et celle-là, qu'elle réponde quitte à se rattraper après ». CAP ne se choisit pas pour un système ; il se choisit pour chaque vérité qu'il garde.So the reflex isn't 'our system is CP' or 'our system is AP', like a label set once: it's 'this datum, when the network cuts, I want it to refuse rather than lie — and that one, to answer even if it catches up afterward'. CAP isn't chosen for a system; it's chosen for each truth it keeps.

Mot de l'éditeur — et fin de la sérieFrom the editor — and end of the series

Nous finissons sur un théorème, et ce n'est pas un hasard. Le cache du #1 copiait une vérité pour la lire vite ; le sharding du #2 la découpait pour qu'elle tienne ; CAP dit ce qui arrive à toute vérité qu'on a, d'une manière ou d'une autre, dédoublée — et il le dit sous forme d'impossibilité. Pas un pattern de plus à ajouter à la boîte, mais une limite qui borne tous les autres : il n'existe pas de système distribué qui soit, pendant une coupure, à la fois juste et disponible. On ne contourne pas une impossibilité ; on choisit de quel côté tomber, et on l'assume.We end on a theorem, and that's no accident. Issue #1's cache copied a truth to read it fast; issue #2's sharding split it so it would fit; CAP says what happens to any truth you've, one way or another, doubled — and it says it as an impossibility. Not one more pattern to add to the box, but a limit that bounds all the others: no distributed system is, during a cut, both correct and available. You don't dodge an impossibility; you choose which side to fall on, and you own it.

C'est, en une image, ce que cette série aura répété de bout en bout : il n'existe pas de geste gratuit. Chaque pattern résout un problème en en achetant un autre, et l'architecture n'est pas la collection des solutions — c'est la lucidité sur les prix. Le découplage qu'on a célébré au début se paie en latence et en cohérence à terme ; la résilience du Vol 7 se paie en idempotence et en complexité ; la vitesse de ce dernier volume se paie en fraîcheur, en transactions perdues, et finalement en ce choix CAP qu'aucune ingéniosité n'efface. Le débutant cherche le bon pattern ; l'architecte connaît le coût de chacun, et choisit lequel payer ici, sur cette donnée, pour ce métier. C'est tout. C'est immense.That, in one image, is what this series will have repeated from end to end: there's no free gesture. Each pattern solves a problem by buying another, and architecture isn't the collection of solutions — it's clarity about the prices. The decoupling celebrated at the start is paid in latency and eventual consistency; Vol 7's resilience is paid in idempotency and complexity; this final volume's speed is paid in freshness, in lost transactions, and finally in this CAP choice no ingenuity erases. The beginner looks for the right pattern; the architect knows the cost of each, and chooses which to pay here, on this datum, for this domain. That's all. That's everything.

Neuf volumes, et une seule question, posée chaque fois sous un angle nouveau : « qu'est-ce que ça coûte, et suis-je prêt à le payer ? » Si tu la poses désormais par réflexe — devant un cache comme devant un disjoncteur, un event store ou une frontière de service —, alors la série a fait son travail, et tu n'as plus besoin d'elle. Merci de l'avoir lue jusqu'ici. La boucle est bouclée.Nine volumes, and a single question, asked each time from a new angle: 'what does it cost, and am I willing to pay it?' If you now ask it by reflex — facing a cache as facing a circuit breaker, an event store, or a service boundary —, then the series has done its work, and you no longer need it. Thank you for reading this far. The loop is closed.

Les voisins que ce numéro débloqueThe neighbors this issue unlocks

• Eventual consistency — la garantie qu'offre le côté A de CAP, souvent mal entendue. Elle ne dit pas « le système est incohérent », mais « en l'absence de nouvelles écritures, toutes les copies finissent par converger ». C'est le contrat des systèmes AP : on répond toujours, on accepte une fenêtre de divergence de quelques millisecondes, et on garantit la convergence — à condition de l'avoir conçue (last-write-wins, fusion métier, ou CRDT, ces types de données qui fusionnent sans conflit par construction). Tolérer la cohérence à terme, c'est accepter un décalage borné en échange d'une disponibilité totale.the guarantee CAP's A side offers, often misheard. It doesn't say 'the system is inconsistent', but 'absent new writes, all copies eventually converge'. It's the contract of AP systems: you always answer, accept a divergence window of a few milliseconds, and guarantee convergence — provided you designed it (last-write-wins, business merge, or CRDTs, those data types that merge without conflict by construction). Tolerating eventual consistency means accepting a bounded lag in exchange for total availability.
• Quorum (R + W > N) — le curseur concret entre C et A. Sur N réplicas, on exige qu'une écriture soit confirmée par W d'entre eux et une lecture par R. Si R + W > N, lecture et écriture se recouvrent forcément sur au moins un réplica à jour : cohérence forte. En abaissant R ou W, on gagne en disponibilité et en latence ce qu'on perd en garantie. Le quorum n'est pas un réglage binaire CP/AP : c'est la molette qui permet de doser, par opération, exactement où l'on place le compromis du théorème.the concrete cursor between C and A. Over N replicas, you require a write to be confirmed by W of them and a read by R. If R + W > N, read and write necessarily overlap on at least one up-to-date replica: strong consistency. By lowering R or W, you gain in availability and latency what you lose in guarantee. The quorum isn't a binary CP/AP setting: it's the dial that lets you tune, per operation, exactly where you place the theorem's trade-off.
• PACELC — l'extension qui complète CAP pour les 99 % du temps où le réseau tient. Elle se lit : si Partition, alors Availability vs Consistency (c'est CAP) ; sinon (Else), Latency vs Consistency. Autrement dit, la cohérence forte a un coût même sans panne — chaque lecture garantie « à jour » impose d'attendre plusieurs réplicas. PACELC rappelle que le compromis de CAP n'était qu'un cas particulier d'un compromis permanent entre cohérence et rapidité, et qu'aucune garantie n'est jamais gratuite — la note exacte sur laquelle cette série choisit de s'achever.the extension that completes CAP for the 99% of the time the network holds. It reads: if Partition, then Availability vs Consistency (that's CAP); else, Latency vs Consistency. In other words, strong consistency has a cost even without a failure — every read guaranteed 'up to date' requires waiting on several replicas. PACELC reminds that CAP's trade-off was only a special case of a permanent one between consistency and speed, and that no guarantee is ever free — the exact note on which this series chooses to end.

Le kata de décision — tranche avant de déroulerThe decision kata — settle it before you scroll

CAP ne s'écrit pas en trente lignes : il se décide. Voici trois données réelles, chacune répliquée sur plusieurs nœuds. Pour chacune, une seule question — sous partition, CP (refuser pour rester juste) ou AP (répondre au risque du périmé) ? — et, quand c'est AP, la question qui compte vraiment : comment converge-t-on ? Parie avant de dérouler ; la réponse tient sur le coût comparé des deux fautes, pas sur une préférence.CAP isn't written in thirty lines: it's decided. Here are three real data items, each replicated across several nodes. For each, one question — under partition, CP (refuse to stay correct) or AP (answer at the risk of staleness)? — and, when it's AP, the question that really counts: how do you converge? Bet before you scroll; the answer rests on the compared cost of the two faults, not on a preference.