Come funziona il request routing di DynamoDB

Ogni lettura o scrittura che invii colpisce prima una flotta di request router stateless. Un router fa l'hash della tua partition key, mappa l'hash al nodo di storage che possiede i dati di quella chiave e inoltra lì la richiesta. Quell'unico hop è perché una ricerca per chiave costa lo stesso che la tabella contenga mille item o un miliardo.

Come funziona il request routing di DynamoDB?

DynamoDB instrada ogni richiesta attraverso una flotta di request router stateless che fa l'hash della tua partition key, mappa l'hash all'unico nodo di storage che possiede quella partizione e inoltra lì la lettura o la scrittura. Il routing è una funzione pura dell'hash della chiave, quindi una singola ricerca ha lo stesso costo che la tabella contenga mille item o un miliardo.

• Il request router è la porta d'ingresso. È una flotta stateless che prende la tua richiesta, fa l'hash della partition key e la instrada al nodo di storage che contiene quella partizione — niente scansioni, nessuna conoscenza dell'intera tabella necessaria.
• La partition key decide tutto. Il routing è una funzione pura dell'hash della partition key. Stessa chiave, stesso nodo, ogni volta — così GetItem è O(1), non O(dimensione tabella).
• Un primario, due secondari. Una scrittura atterra sul nodo primario della partizione, che replica a due secondari tra le Availability Zone prima che sia durevole.
• Le chiavi sbagliate sconfiggono il design. Una partition key a bassa cardinalità o "calda" convoglia il traffico su un solo nodo — il routing va bene, la tua chiave è il problema.

Inizia dal problema che il routing risolve

Venendo da SQL, immagini un query planner: legge le statistiche, sceglie un index, magari scansiona. Il costo scala con quanti dati tocca. Quel modello non si adatta a un key-value store che deve rispondere in millisecondi a una cifra a qualsiasi dimensione.

La risposta di DynamoDB è rendere una ricerca di un singolo item un indirizzo diretto, non una ricerca. La partition key non è una colonna su cui filtri — è l'input a una funzione di hash che calcola dove vivono fisicamente i dati. Niente statistiche, niente planner.

È lo scambio che accetti quando ti allontani dal pensiero relazionale: rinunci alla flessibilità delle query ad-hoc e ottieni in cambio l'indirizzamento a tempo costante.

Conosci il request router

Quando arriva una richiesta, non va dritta allo storage. Colpisce un request router — una flotta stateless e scalata orizzontalmente che fa da fronte all'intero servizio. (Le sessioni AWS re:Invent "DynamoDB Deep Dive" descrivono questa flotta di front-end.)

Il router fa tre cose e non contiene dati propri:

• Autentica e autorizza la richiesta contro IAM.
• Fa l'hash della partition key per trovare la partizione che la possiede.
• Inoltra la richiesta al nodo di storage per quella partizione.

Poiché i router sono stateless, il servizio ne aggiunge altri sotto carico. Nessuno di essi è un collo di bottiglia e nessuno è un singolo punto di guasto — la stessa proprietà intorno a cui il paper Amazon Dynamo del 2007 ha costruito il sistema originale.

Segui una lettura attraverso il router

Prendi una tabella di telemetria per una flotta di droni. Gli item hanno chiavi DroneId (partition key) e ReadingTs (sort key), con attributi come BatteryPct e AltitudeM.

Chiedi l'ultima lettura per un drone:

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

Ecco cosa fa il router con essa. L'introduzione qui sotto traccia la richiesta dall'alto al basso — leggila come un unico flusso verso il basso.

Il router fa l'hash di DRONE#A19F, lo mappa alla partizione che possiede quella chiave e inoltra la lettura al nodo di storage primario di quella partizione, che restituisce l'item.

L'intuizione chiave: l'hash punta a una partizione su quante ne abbia la tabella. Il router non guarda mai le altre partizioni, quindi aggiungere droni — e partizioni — non rallenta questa ricerca.

Sappi cos'è davvero una partizione

Una partizione è un'unità di storage e throughput. Ognuna è limitata (circa 10 GB e una fetta fissa di capacità di lettura/scrittura), e DynamoDB divide una partizione quando supera l'uno o l'altro limite. Ogni item con una data partition key vive sulla stessa partizione, che è ciò che rende economica una Query su una partition key.

Ogni partizione è replicata su tre nodi di storage distribuiti tra le Availability Zone: un primario e due secondari.

Una scrittura va al primario, che replica ai secondari prima di confermare la durabilità. Una lettura fortemente coerente è instradata al primario così che rifletta l'ultima scrittura. Una lettura eventualmente coerente può essere servita da un secondario che non ha ancora recuperato — metà del costo, possibilmente stantia.

Nomina il footgun: una hot partition key

Il routing è buono solo quanto la tua partition key. L'hash distribuisce le chiavi uniformemente, quindi se le tue chiavi hanno alta cardinalità e traffico uniforme, il carico si distribuisce tra tutti i nodi. Rompi l'una o l'altra proprietà e ottieni una hot partition.

Diciamo che metti in chiave quella telemetria per Region invece che per DroneId. Ora ogni drone in us-east-1 condivide una partition key — quindi ognuna delle loro letture e scritture fa l'hash sullo stesso nodo. Il router sta facendo il suo lavoro perfettamente; hai solo convogliato l'intera flotta sulla capacità di una singola partizione.

Non puoi guardare il router scegliere un nodo, ma puoi progettare chiavi che si instradano bene. Quando costruisci una condizione di chiave nell'Expression Builder, la partition key che metti a sinistra di PK = … è l'esatto valore di cui il router farà l'hash — mantenere quel valore ad alta cardinalità è ciò che mantiene le letture su nodi separati.

Come questo si ricollega ai tuoi access pattern

Il request routing è il meccanismo che rende le regole del single-table design non negoziabili: modelli intorno alla partition key perché la partition key è l'indirizzo. È anche perché una Query batte uno Scan — una Query colpisce una partizione attraverso il router, mentre uno Scan percorre ogni partizione in sequenza.

Gli index secondari ottengono le proprie partizioni e il proprio routing: un GSI è instradato per la propria partition key, indipendente da quella della tabella base, ed è per questo che un GSI può essere caldo anche quando la tabella non lo è.

Prossimi passi

Progetta chiavi che si instradino verso molti nodi, non uno. Abbozza la condizione PK = … nell'Expression Builder per vedere esattamente quale valore viene hashato, poi scarica DynoTable per eseguire quelle query sulle tue tabelle e guardare quali partition key portano davvero il tuo traffico.