Comment fonctionne le routage des requêtes DynamoDB

Chaque lecture ou écriture que tu envoies touche d'abord une flotte de request routers sans état. Un router hache ta clé de partition, mappe le hash au nœud de stockage qui détient les données de cette clé, et y achemine la requête. Ce seul saut est pourquoi une recherche par clé coûte la même chose que la table contienne mille items ou un milliard.

Comment fonctionne le routage des requêtes DynamoDB ?

DynamoDB achemine chaque requête via une flotte de request routers sans état qui hachent ta clé de partition, mappent le hash au nœud de stockage unique détenant cette partition, et y transfèrent la lecture ou l'écriture. Le routage est une fonction pure du hash de la clé, donc une recherche coûte la même chose que la table contienne mille items ou un milliard.

• Le request router est la porte d'entrée. C'est une flotte sans état qui prend ta requête, hache la clé de partition, et la route vers le nœud de stockage détenant cette partition — pas de scan, pas besoin de connaître toute la table.
• La clé de partition décide de tout. Le routage est une fonction pure du hash de la clé de partition. Même clé, même nœud, à chaque fois — donc GetItem est en O(1), pas en O(taille de la table).
• Un primaire, deux secondaires. Une écriture atterrit sur le nœud primaire de la partition, qui réplique vers deux secondaires à travers les zones de disponibilité avant qu'elle ne soit durable.
• De mauvaises clés sabotent le design. Une clé de partition à faible cardinalité ou « chaude » canalise le trafic vers un seul nœud — le routage est bon, c'est ta clé qui est le problème.

Commence par le problème que le routage résout

En venant de SQL, tu imagines un planificateur de requêtes : il lit des statistiques, choisit un index, scanne peut-être. Le coût évolue avec la quantité de données qu'il touche. Ce modèle ne convient pas à un magasin clé-valeur qui doit répondre en millisecondes à un chiffre quelle que soit la taille.

La réponse de DynamoDB est de faire d'une recherche d'item unique une adresse directe, pas une recherche. La clé de partition n'est pas une colonne sur laquelle tu filtres — c'est l'entrée d'une fonction de hash qui calcule où les données vivent physiquement. Pas de statistiques, pas de planificateur.

C'est le compromis que tu acceptes quand tu quittes la pensée relationnelle : tu abandonnes la flexibilité de requête ad hoc et tu obtiens un adressage à temps constant en échange.

Rencontre le request router

Quand une requête arrive, elle ne va pas directement au stockage. Elle touche un request router — une flotte sans état, scalée horizontalement, qui fronte tout le service. (Les sessions re:Invent « DynamoDB Deep Dive » d'AWS décrivent cette flotte frontale.)

Le router fait trois choses et ne détient aucune donnée propre :

• Authentifie et autorise la requête contre IAM.
• Hache la clé de partition pour trouver la partition qui la détient.
• Achemine la requête vers le nœud de stockage de cette partition.

Parce que les routers sont sans état, le service en ajoute davantage sous charge. Aucun d'eux n'est un goulot d'étranglement et aucun n'est un point de défaillance unique — la même propriété autour de laquelle le papier Amazon Dynamo de 2007 a construit le système d'origine.

Suis une lecture à travers le router

Prenons une table de télémétrie pour une flotte de drones. Les items sont clés par DroneId (clé de partition) et ReadingTs (clé de tri), avec des attributs comme BatteryPct et AltitudeM.

Tu demandes la dernière mesure d'un drone :

PK = "DRONE#A19F"
SK begins_with "2026-06-23"

Voici ce que le router en fait. L'introduction ci-dessous trace la requête de haut en bas — lis-la comme un seul flux descendant.

Le router hache DRONE#A19F, le mappe à la partition qui détient cette clé, et achemine la lecture vers le nœud de stockage primaire de cette partition, qui renvoie l'item.

L'insight clé : le hash pointe vers une partition parmi le nombre qu'a la table. Le router ne regarde jamais les autres partitions, donc ajouter des drones — et des partitions — ne ralentit pas cette recherche.

Sache ce qu'est réellement une partition

Une partition est une unité de stockage et de débit. Chacune est plafonnée (environ 10 Go et une tranche fixe de capacité de lecture/écriture), et DynamoDB scinde une partition quand elle dépasse l'une ou l'autre limite. Chaque item avec une clé de partition donnée vit sur la même partition, ce qui rend un Query sur une clé de partition bon marché.

Chaque partition est répliquée sur trois nœuds de stockage répartis sur les zones de disponibilité : un primaire et deux secondaires.

Une écriture va au primaire, qui réplique vers les secondaires avant d'acquitter la durabilité. Une lecture fortement cohérente est routée vers le primaire pour qu'elle reflète la dernière écriture. Une lecture à cohérence à terme peut être servie par un secondaire qui n'a pas encore rattrapé — moitié du coût, possiblement périmée.

Nomme le piège : une clé de partition chaude

Le routage n'est aussi bon que ta clé de partition. Le hash répartit les clés uniformément, donc si tes clés ont une forte cardinalité et un trafic homogène, la charge se répartit sur tous les nœuds. Brise l'une ou l'autre propriété et tu obtiens une partition chaude.

Disons que tu clés cette télémétrie par Region au lieu de DroneId. Maintenant chaque drone de us-east-1 partage une seule clé de partition — donc chacune de leurs lectures et écritures se hache vers le même nœud. Le router fait parfaitement son boulot ; tu as juste canalisé toute la flotte vers la capacité d'une seule partition.

Tu ne peux pas regarder le router choisir un nœud, mais tu peux concevoir des clés qui routent bien. Quand tu construis une condition de clé dans le constructeur d'expressions, la clé de partition que tu mets à gauche de PK = … est la valeur exacte que le router va hacher — garder cette valeur à forte cardinalité est ce qui maintient les lectures sur des nœuds séparés.

Comment ça se rattache à tes access patterns

Le routage des requêtes est le mécanisme qui rend les règles du single-table design non négociables : tu modélises autour de la clé de partition parce que la clé de partition est l'adresse. C'est aussi pourquoi un Query bat un Scan — un Query touche une partition à travers le router, alors qu'un Scan parcourt chaque partition en séquence.

Les index secondaires obtiennent leurs propres partitions et leur propre routage : un GSI est routé par sa propre clé de partition, indépendante de celle de la table de base, ce qui explique pourquoi un GSI peut être chaud même quand la table ne l'est pas.

Étapes suivantes

Conçois des clés qui routent vers plusieurs nœuds, pas un seul. Esquisse la condition PK = … dans le constructeur d'expressions pour voir exactement quelle valeur est hachée, puis télécharge DynoTable pour lancer ces requêtes contre tes propres tables et regarder quelles clés de partition portent réellement ton trafic.