Comment fonctionne le routage des requêtes DynamoDB

Chaque lecture ou écriture que tu envoies frappe d'abord une flotte de request routers sans état. Un router hashe ta partition key, mappe le hash au storage node qui possède les données de cette clé, et y forward la requête. Ce hop unique est pourquoi un lookup de clé coûte la même chose que le table tienne mille items ou un milliard.

Comment fonctionne le routage des requêtes DynamoDB ?

DynamoDB route chaque requête via une flotte de request routers sans état qui hashe ta partition key, mappe le hash au seul storage node qui possède cette partition, et y forward la lecture ou l'écriture. Le routage est une fonction pure du hash de la clé, donc un lookup coûte la même chose que le table tienne 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, hashe la partition key, et la route vers le storage node qui tient cette partition — pas de scanning, pas de connaissance full-table nécessaire.
• La partition key décide de tout. Le routage est une fonction pure du hash de la partition key — la même clé route toujours vers la partition qui la possède, donc GetItem est O(1), pas O(taille du table).
• Un primary, deux secondaries. Une écriture atterrit sur le nœud primary de la partition, qui acknowledge une fois qu'un quorum (deux des trois replicas) l'a persistée.
• De mauvaises clés défont le design. Une partition key à faible cardinalité ou « hot » funnel le trafic vers un nœud — le routage va bien, ta clé est le problème.

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

Venant de SQL, tu imagines un query planner : il lit des statistiques, choisit un index, peut-être scanne. Le coût scale avec la quantité de données touchées. Ce modèle ne convient pas à un store key-value qui doit répondre en millisecondes à un chiffre à n'importe quelle taille.

La réponse de DynamoDB est de faire d'un lookup single-item une adresse directe, pas une recherche. La partition key est l'entrée d'une fonction de hash qui calcule où les données vivent physiquement — pas une colonne sur laquelle tu filtres. Pas de statistiques, pas de planner.

C'est le trade que tu acceptes quand tu quittes la pensée relationnelle : tu abandonnes la flexibilité de query ad hoc et tu gagnes l'adressage à temps constant en retour.

Rencontre le request router

Quand une requête arrive, elle ne va pas directement au stockage. Elle frappe un request router — une flotte sans état, scalée horizontalement, qui front tout le service. (Le papier DynamoDB USENIX ATC '22 décrit cette flotte de request routers.)

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

• Authentifie et autorise la requête contre IAM.
• Hashe la partition key pour trouver la partition qui la possède.
• Forward la requête vers le storage node de cette partition.

Parce que les routers sont sans état, le service en ajoute sous charge. Aucun n'est un bottleneck et aucun n'est un single point of failure — la même propriété autour de laquelle le papier Amazon Dynamo 2007 a construit le système original.

Suis une lecture à travers le router

Prends un table de télémétrie pour une flotte de drones. Les items sont keyed par DroneId (partition key) et ReadingTs (sort key), avec des attributs comme BatteryPct et AltitudeM.

Tu demandes les readings d'un drone du 23 juin :

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

Le diagramme ci-dessous trace la requête de haut en bas — lis-le comme un flux descendant.

Le router hashe DRONE#A19F, le mappe à la partition qui possède cette clé, et forward la lecture vers le storage node primary de cette partition, qui renvoie l'item.

Le hash pointe vers une partition parmi autant que le table en a. Le router ne regarde jamais les autres partitions, donc ajouter des drones — et des partitions — ne ralentit pas ce lookup.

Sache ce qu'est vraiment une partition

Une partition est une unité de stockage et de throughput. Chacune est plafonnée (environ 10 GB et une tranche fixe de capacité lecture/écriture), et DynamoDB split une partition quand elle dépasse l'une ou l'autre limite. Chaque item avec une partition key donnée commence sur une partition ; le split-for-heat peut plus tard découper cette collection par plage de sort key (sauf si un LSI ou une sort key monotone la pin), ce qui rend encore un Query sur une partition key bon marché.

Chaque partition est répliquée sur trois storage nodes répartis entre Availability Zones : un primary et deux secondaries.

Une écriture va au primary, qui acknowledge une fois qu'un quorum (deux des trois replicas) l'a persistée. Une lecture strongly consistent est routée vers le primary pour qu'elle reflète la dernière écriture. Une lecture eventually consistent peut être servie par un secondary qui n'a pas encore rattrapé — moitié du coût, éventuellement périmé.

Nomme le footgun : une partition key chaude

Le routage n'est aussi bon que ta partition key. Le hash étale les clés uniformément, donc si tes clés ont une haute cardinalité et un trafic uniforme, la charge s'étale sur tous les nœuds. Casse l'une ou l'autre propriété et tu obtiens une hot partition.

Disons que tu key cette télémétrie par Region au lieu de DroneId. Maintenant chaque drone dans us-east-1 partage une partition key — donc leurs lectures et écritures hashe vers le même slot keyspace et s'empilent sur une item collection. Le router fait parfaitement son job ; tu viens juste de funnel 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 key condition dans l' Expression Builder, la partition key que tu mets à gauche de PK = … est la valeur exacte que le router hashera — garder cette valeur à haute cardinalité est ce qui garde les lectures sur des nœuds séparés.

Comment ça se relie à tes modèles d'accès

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 partition key parce que la partition key est l'adresse. C'est aussi pourquoi un Query bat un Scan — un Query frappe une partition via le router, tandis qu'un Scan parcourt chaque partition en séquence.

Les secondary indexes ont leurs propres partitions et leur propre routage : un GSI est routé par sa propre partition key, indépendante de celle du table de base, c'est pourquoi un GSI peut être hot même quand le table ne l'est pas.

Étapes suivantes

Conçois des clés qui routent vers beaucoup de nœuds, pas un. Esquisse la condition PK = … dans l' Expression Builder pour voir exactement quelle valeur est hashée, puis télécharge DynoTable pour lancer ces queries contre tes propres tables et voir exactement ce que chaque key condition renvoie.