Sharding, ou la donnée qu'on découpe et la clé qu'on ne peut plus changerSharding, or the data you split and the key you can no longer change

Une machine ne suffit plus. On découpe la donnée — mais le découpage choisit ce qui restera rapide.One machine no longer suffices. You split the data — but the split decides what stays fast.

Le numéro précédent gardait une seule source de vérité et s'en faisait des copies pour lire vite. Mais que faire quand la source elle-même ne tient plus — quand la donnée est trop grosse pour une seule machine, ou les écritures trop nombreuses pour un seul nœud ? Le cache n'aide plus : il accélère la lecture, pas la capacité d'écriture ni le stockage. On grossit d'abord la machine — plus de RAM, plus de disque, plus de CPU : c'est le scaling vertical, simple, et il a un plafond, et un prix qui explose près du plafond. Au-delà, il faut découper la donnée en morceaux — des shards — répartis sur plusieurs machines, chacune ne portant qu'une part du tout : c'est le sharding, le scaling horizontal. La promesse est belle : capacité et débit qui croissent en ajoutant des machines. Le piège est dans le découpage : on choisit une clé de partition, et cette clé décide pour toujours quelles requêtes resteront rapides — et lesquelles devront traverser toutes les machines. Le réflexe complet n'est donc pas « répartis sur N machines », c'est « choisis la clé selon laquelle on lit le plus, car c'est elle qu'on ne pourra plus changer » — et, règle du volume, on n'y entre qu'avec un chiffre : un volume ou un débit mesuré qui dépasse vraiment une seule machine.The previous issue kept a single source of truth and copied it to read fast. But what to do when the source itself no longer fits — when the data is too big for one machine, or the writes too many for a single node? The cache no longer helps: it speeds reads, not write capacity nor storage. You first grow the machine — more RAM, more disk, more CPU: that's vertical scaling, simple, and it has a ceiling, and a price that explodes near the ceiling. Beyond it, you must split the data into pieces — shards — spread across several machines, each carrying only a part of the whole: that's sharding, horizontal scaling. The promise is fine: capacity and throughput that grow by adding machines. The trap is in the split: you choose a partition key, and that key decides forever which queries stay fast — and which must cross every machine. So the full reflex isn't 'spread it over N machines', it's 'choose the key you read by the most, because it's the one you can no longer change' — and, the volume's rule, you only enter with a number: a measured volume or throughput that truly exceeds one machine.

# une seule base sature. le réflexe : « répartis sur N machines ». la moitié du geste seulement.
SHARDS = [db0, db1, db2, db3]
def shard_for(user_id):
    return SHARDS[hash(user_id) % len(SHARDS)]   # 💥 modulo N : ajouter une machine REHACHE tout

def get_orders(user_id):
    return shard_for(user_id).query(             # ✓ requête par user_id : une seule machine, rapide
        "SELECT * FROM orders WHERE user_id = ?", user_id)

def orders_in_region(region):
    # 💥 la région n'est pas la clé de shard → on doit interroger TOUTES les machines
    return merge(s.query("SELECT * FROM orders WHERE region = ?", region) for s in SHARDS)
# un sharding sans clé bien choisie n'est pas du scaling : c'est un éparpillement qu'on paie à chaque requête.

La requête se disperse, la transaction se brise, et une machine porte la moitié du monde.The query scatters, the transaction breaks, and one machine carries half the world.

Découper la donnée a trois coûts, et aucun n'apparaît tant que les requêtes suivent sagement la clé — tous surgissent dès qu'on en sort. D'abord la requête se disperse : toute recherche qui n'est pas par la clé de partition doit interroger chaque machine et fusionner les réponses (scatter-gather), et elle n'est jamais plus rapide que le shard le plus lent. Ensuite la transaction se brise : une opération qui touche deux shards ne peut plus être atomique gratuitement — on retombe sur les sagas et l'idempotence du Vol 7, ou sur un coûteux commit distribué. Enfin la distribution dérape : si la clé est mal choisie — peu de valeurs distinctes, ou une valeur dominante —, une machine hérite d'une part disproportionnée du trafic et des données : c'est le hot shard, un goulot qu'on a recréé à l'intérieur même de la solution censée l'éliminer. Trois douleurs qu'une clé bien choisie réduit, mais que la mauvaise amplifie.Splitting the data has three costs, and none shows as long as queries dutifully follow the key — all surge the moment you step off it. First the query scatters: any search that isn't by the partition key must query every machine and merge the answers (scatter-gather), and it's never faster than the slowest shard. Then the transaction breaks: an operation touching two shards can no longer be atomic for free — you fall back to Vol 7's sagas and idempotency, or to a costly distributed commit. Finally the distribution skews: if the key is badly chosen — few distinct values, or one dominant value —, one machine inherits a disproportionate share of traffic and data: that's the hot shard, a bottleneck recreated inside the very solution meant to remove it. Three pains a good key reduces, but the wrong one amplifies.

# clé de partition = pays. 80 % des clients sont en France → shard "FR" prend 80 % du trafic.
def shard_for(customer):
    return shard_by_country[customer.country]   # 💥 hot shard : "FR" cuit, "IS"/"LU" dorment

# le tableau de bord trie les commandes récentes, toutes régions confondues :
def recent_orders(limit=50):
    # 💥 region ≠ clé → on diffuse à TOUS les shards, chacun renvoie 50, on refusionne et retrie
    rows = scatter(s.query("SELECT * FROM orders ORDER BY created_at DESC LIMIT 50") for s in SHARDS)
    return sort(rows, by="created_at")[:50]      # latence = celle du shard le plus lent

# transfert entre deux clients sur deux shards différents :
def transfer(a, b, amount):
    shard_for(a).debit(a, amount)                # 💥 et si la 2ᵉ ligne échoue ? le débit reste,
    shard_for(b).credit(b, amount)               #    plus de transaction commune → incohérence

Saturée, découpée, ciblée, dispersée — la requête est rapide tant qu'elle suit la clé.Saturated, split, targeted, scattered — the query is fast as long as it follows the key.

Le sharding ne se comprend pas comme « plus de machines », mais comme un routage. L'animation suit une seule décision — la clé de partition — à travers ses conséquences : la machine unique qui sature, le découpage par hash qui étale la charge, la requête par la clé qui ne touche qu'un shard, la requête hors clé qui doit tous les interroger, et la clé mal choisie qui recrée un goulot. Surveille la charge de chaque shard et les machines qu'éclaire la requête courante : c'est l'écart entre « un shard touché » et « tous les shards touchés » qui raconte pourquoi le choix de la clé est toute l'affaire.Sharding isn't understood as 'more machines', but as routing. The animation follows a single decision — the partition key — through its consequences: the single machine saturating, the hash split that spreads the load, the query by the key that hits one shard, the off-key query that must ask them all, and the badly chosen key that recreates a bottleneck. Watch each shard's load and the machines the current query lights up: it's the gap between 'one shard hit' and 'all shards hit' that tells why the key choice is the whole affair.

def route(user_id):▸ à toiyour turn — à partir d'une clé, comment désigner le shard sans tout rehacher quand on ajoute une machine ?from a key, how do you pick the shard without rehashing everything when a machine is added? · cliquer pour révélerclick to reveal
def get_orders(user_id):
    return route(user_id).query(                  # ALIGNÉ sur la clé → un seul shard, rapide
        "SELECT * FROM orders WHERE user_id = ?", user_id)

def recent_orders_global(limit):
    # HORS clé → scatter-gather : on demande à tous, on refusionne, on retrie▸ à toiyour turn — requête hors clé : à qui doit-on la poser pour pouvoir répondre, avant de refusionner ?off-key query: whom must you ask in order to answer, before re-merging? · cliquer pour révélerclick to reveal    return sort(parts, by="created_at", desc=True)[:limit]   # latence = celle du shard le plus lent
# règle : on choisit la clé d'après la requête la PLUS fréquente, pour que le scatter reste l'exception.

Shard trop tôt, ou shard sur la mauvaise clé.Shard too early, or shard on the wrong key.

Deux dérives encadrent le bon usage, et elles naissent du même défaut — ne pas avoir regardé le chiffre. La première shard trop tôt : le goulot était en lecture, qu'un réplica ou un cache aurait absorbé, ou bien le volume n'avait jamais approché le plafond d'une grosse machine. On a payé toute la complexité du distribué — scatter-gather, transactions perdues, exploitation — pour une capacité dont on n'avait pas besoin. La seconde shard sur la mauvaise clé : on découpe par un attribut à faible cardinalité ou monotone — la date, le pays, un statut —, et le trafic se concentre sur un shard pendant que les autres dorment. La première dérive ajoute du coût sans bénéfice ; la seconde recrée le goulot à l'intérieur de la solution, et le réparer impose de changer la clé, donc de tout migrer. Bascule le toggle : repère le sharding qu'aucun chiffre n'appelait, et la clé qu'aucun équilibre ne justifie.Two drifts frame correct use, and they spring from the same flaw — not having looked at the number. The first shards too early: the bottleneck was reads, which a replica or cache would have absorbed, or else the volume had never approached a big machine's ceiling. You paid all the distributed complexity — scatter-gather, lost transactions, operations — for capacity you didn't need. The second shards on the wrong key: you split by a low-cardinality or monotonic attribute — the date, the country, a status —, and traffic concentrates on one shard while the others sleep. The first drift adds cost with no benefit; the second recreates the bottleneck inside the solution, and fixing it forces changing the key, hence migrating everything. Flip the toggle: spot the sharding no number called for, and the key no balance justifies.

# on a MESURÉ : 4 To de données, 60 000 écritures/s — la plus grosse machine plafonne à 2 To / 20k.
# le scaling vertical est épuisé, les réplicas en lecture ne servent à rien (le goulot est l'ÉCRITURE).
# → sharding justifié. clé = tenant_id : forte cardinalité, et 95 % des requêtes portent ce tenant.
def route(tenant_id):
    return SHARDS[consistent_hash(tenant_id)]     # ✓ +1 machine ne déplace qu'1/N des données

def get_invoices(tenant_id):                      # ✓ aligné sur la clé → un seul shard
    return route(tenant_id).query("SELECT * FROM invoices WHERE tenant_id = ?", tenant_id)

def add_invoice(tenant_id, inv):                  # ✓ entité co-localisée avec son tenant
    route(tenant_id).insert("invoices", {**inv, "tenant_id": tenant_id})
# tenant + ses factures vivent sur le MÊME shard → la transaction reste locale, pas de cross-shard.

Plus de capacité, ou plus de simplicité — le sharding échange l'une contre l'autre.More capacity, or more simplicity — sharding trades one for the other.

Quand ne pas (encore) shardWhen not to shard (yet)

Le sharding a un loyer permanent : des requêtes croisées, des transactions distribuées, une exploitation plus lourde, et une clé qu'on ne pourra plus changer sans tout migrer. On garde une seule base — et c'est correct, souvent préférable — quand :Sharding has permanent rent: cross-shard queries, distributed transactions, heavier operations, and a key you can no longer change without migrating everything. You keep a single database — and that's fine, often preferable — when:

• le scaling vertical n'est pas épuisé : une machine plus grosse tient encore le volume et le débit. Tant que le plafond n'est pas atteint et mesuré, grossir la machine reste plus simple, plus sûr et moins cher que distribuer (la règle : on n'entre dans la scalabilité qu'avec un chiffre).vertical scaling isn't exhausted: a bigger machine still holds the volume and throughput. Until the ceiling is reached and measured, growing the machine stays simpler, safer and cheaper than distributing (the rule: you enter scalability only with a number).
• le goulot est en lecture : un réplica en lecture ou un cache (le #1) absorbe la charge sans rien découper. Sharder pour un problème de lecture, c'est payer la complexité de l'écriture distribuée pour rien. On ne shard que quand l'écriture ou le stockage saturent.the bottleneck is reads: a read replica or a cache (#1) absorbs the load without splitting anything. Sharding for a read problem means paying for distributed-write complexity for nothing. You shard only when writes or storage saturate.
• les axes d'accès ne sont pas stables : si on ne sait pas encore par quoi on lira le plus dans six mois, figer une clé de partition revient à parier — et un mauvais pari se paie en scatter-gather permanent et en migration. On attend que le schéma de requêtes se stabilise avant de graver la clé.the access axes aren't stable: if you don't yet know what you'll read by most in six months, freezing a partition key is a bet — and a bad bet is paid in permanent scatter-gather and migration. You wait for the query pattern to stabilize before carving the key.

Le réflexe n'est donc pas « ça grossit, shardons » : c'est « ai-je atteint le plafond d'une seule machine en écriture ou en stockage, mesuré, et sais-je par quelle clé stable on lit le plus ? Alors shard, en co-localisant et en hachant de façon cohérente. Sinon, grossis la machine ou réplique en lecture — c'est plus simple, et la simplicité est une capacité aussi. »So the reflex isn't 'it's growing, let's shard': it's 'have I reached one machine's ceiling on writes or storage, measured, and do I know which stable key you read by most? Then shard, co-locating and consistent-hashing. Otherwise, grow the machine or replicate reads — it's simpler, and simplicity is a capacity too.'

Mot de l'éditeurFrom the editor

Le cache du #1 gardait une seule source de vérité et la recopiait pour lire vite. Le sharding va plus loin et plus douloureusement : il brise l'unité de la source elle-même. Là où le cache laissait intacte l'illusion d'« un seul endroit où vit la donnée », le sharding y renonce — et avec elle aux deux conforts qu'une base unique offrait sans qu'on les remarque : la requête qui joint tout d'un coup, et la transaction qui change deux choses atomiquement. C'est le prix de la capacité sans plafond. Et c'est la leçon que la série répète sous toutes ses formes : il n'existe pas de geste gratuit. Le débutant voit « plus de machines, plus de puissance » ; l'architecte voit une clé de partition qui décide, pour la vie du système, ce qui sera rapide et ce qui sera dispersé — et il la choisit avec le soin d'une décision qu'on ne révoque pas.Issue #1's cache kept a single source of truth and copied it to read fast. Sharding goes further and more painfully: it breaks the unity of the source itself. Where the cache left intact the illusion of 'one place where the data lives', sharding gives it up — and with it the two comforts a single database offered unnoticed: the query that joins everything at once, and the transaction that changes two things atomically. That's the price of capacity without a ceiling. And it's the lesson the series repeats in every form: there's no free gesture. The beginner sees 'more machines, more power'; the architect sees a partition key that decides, for the system's life, what will be fast and what will be scattered — and chooses it with the care of a decision you don't revoke.

Mais en distribuant la donnée, le sharding fait surgir une question qu'une base unique masquait : pour survivre à la panne d'une machine, on réplique chaque shard sur plusieurs nœuds — et dès qu'une donnée existe en plusieurs exemplaires, il faut les garder d'accord. Que se passe-t-il quand le réseau coupe entre ces copies ? Refuse-t-on de répondre pour rester cohérent, ou répond-on au risque de servir une version périmée ? Aucune réplication n'échappe à ce choix. C'est le sujet du #3, et la note finale de toute la série : le théorème CAP — la preuve qu'un système distribué ne peut, sous partition réseau, être à la fois cohérent et disponible, et qu'architecturer, c'est choisir lequel on sacrifie.But by distributing the data, sharding raises a question a single database hid: to survive one machine's failure, you replicate each shard across several nodes — and once data exists in several copies, you must keep them in agreement. What happens when the network cuts between those copies? Do you refuse to answer to stay consistent, or answer at the risk of serving a stale version? No replication escapes this choice. It's #3's subject, and the final note of the whole series: the CAP theorem — the proof that a distributed system cannot, under a network partition, be both consistent and available, and that to architect is to choose which one you sacrifice.

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

• Consistent hashing — le routage qui rend le sharding évolutif. Au lieu de hash % N — qui change la cible de presque toutes les clés dès qu'on ajoute une machine —, on place machines et clés sur un anneau, et chaque clé revient à la machine suivante. Ajouter ou retirer un nœud ne déplace qu'environ 1/N des données, leurs voisines immédiates sur l'anneau, et non la totalité. C'est ce qui transforme le rééquilibrage d'une migration brutale en une opération de routine — la condition pour qu'un cluster shardé puisse grandir en production.the routing that makes sharding scalable. Instead of hash % N — which changes the target of almost every key the moment you add a machine —, you place machines and keys on a ring, and each key falls to the next machine. Adding or removing a node moves only about 1/N of the data, its immediate ring-neighbors, not all of it. That's what turns rebalancing from a brutal migration into a routine operation — the condition for a sharded cluster to grow in production.
• Replication & read replicas — le pendant du sharding, et souvent son alternative. Là où le sharding découpe la donnée pour la capacité, la réplication la copie pour la disponibilité et la lecture : un primaire pour les écritures, des réplicas qui reçoivent un flux de changements et servent les lectures. C'est la première chose à essayer quand le goulot est en lecture — bien avant de shard. Mais répliquer, c'est créer des copies qui peuvent diverger le temps que le flux les rattrape : la cohérence à terme, et le choix CAP, entrent par cette porte.sharding's counterpart, and often its alternative. Where sharding splits data for capacity, replication copies it for availability and reads: a primary for writes, replicas that receive a change stream and serve reads. It's the first thing to try when the bottleneck is reads — well before sharding. But replicating means creating copies that can diverge while the stream catches up: eventual consistency, and the CAP choice, enter through that door.
• Co-location & shard key — la discipline qui garde les transactions locales. Co-localiser, c'est ranger sur le même shard les entités qu'on lit et modifie ensemble — un tenant et ses factures, un utilisateur et ses commandes — en les faisant partager la clé de partition. Une transaction qui reste dans un shard reste atomique, gratuitement, comme sur une base unique ; une transaction qui le franchit retombe sur les sagas du Vol 7. Choisir la clé de shard, c'est donc moins choisir comment répartir la donnée que choisir quelles opérations resteront simples.the discipline that keeps transactions local. Co-locating means placing on the same shard the entities you read and modify together — a tenant and its invoices, a user and their orders — by making them share the partition key. A transaction that stays within a shard stays atomic, for free, as on a single database; one that crosses it falls back to Vol 7's sagas. Choosing the shard key is therefore less about choosing how to spread the data than about choosing which operations stay simple.

Le kata — écris-le, ne le relis pasThe kata — write it, don't reread it

# test_consistent_hash.py — la spec EST le harnais : fais-le passer au vert.
# un anneau de hachage cohérent : router une clé vers un nœud, et — surtout — ne déplacer
# qu'une FRACTION des clés quand on ajoute ou retire un nœud.

def test_route_est_deterministe():
    ring = Ring(["A", "B", "C"])
    assert ring.route("user:42") == ring.route("user:42")   # même clé → toujours le même nœud

def test_repartit_sur_tous_les_noeuds():
    ring = Ring(["A", "B", "C"])
    cibles = {ring.route(f"user:{i}") for i in range(1000)}
    assert cibles == {"A", "B", "C"}                          # les 3 nœuds reçoivent des clés

def test_charge_a_peu_pres_equilibree():
    ring = Ring(["A", "B", "C"])
    n = Counter(ring.route(f"user:{i}") for i in range(3000))
    assert all(700 < c < 1300 for c in n.values())           # ~1000 chacun, aucun nœud écrasé

def test_retirer_un_noeud_ne_touche_que_ses_cles():
    avant = Ring(["A", "B", "C"])
    apres = Ring(["A", "C"])                                   # B disparaît
    bouge = sum(avant.route(f"k{i}") != apres.route(f"k{i}") for i in range(3000))
    assert bouge < 1300                                        # seules les clés de B se déplacent

def test_ajouter_un_noeud_ne_deplace_qu_une_fraction():
    avant = Ring(["A", "B", "C"])
    apres = Ring(["A", "B", "C", "D"])                         # +1 nœud → ~1/4 des clés bougent
    bouge = sum(avant.route(f"k{i}") != apres.route(f"k{i}") for i in range(4000))
    assert bouge < 1500                                        # PAS 100 % : tout l'écart avec hash % N