Cómo funciona el enrutamiento de peticiones de DynamoDB

Cada lectura o escritura que envías golpea primero una flota de request routers sin estado. Un router hashea tu clave de partición, mapea el hash al nodo de almacenamiento que posee los datos de esa clave, y reenvía la petición allí. Ese único salto es por qué una búsqueda de clave cuesta lo mismo tanto si la tabla contiene mil items como mil millones.

¿Cómo funciona el enrutamiento de peticiones de DynamoDB?

DynamoDB enruta cada petición a través de una flota de request routers sin estado que hashea tu clave de partición, mapea el hash al único nodo de almacenamiento que posee esa partición y reenvía la lectura o escritura allí. El enrutamiento es una función pura del hash de la clave, así que una búsqueda cuesta lo mismo tanto si la tabla contiene mil items como mil millones.

• El request router es la puerta de entrada. Es una flota sin estado que toma tu petición, hashea la clave de partición y la enruta al nodo de almacenamiento que contiene esa partición — sin escanear, sin necesidad de conocimiento de toda la tabla.
• La clave de partición lo decide todo. El enrutamiento es una función pura del hash de la clave de partición. Misma clave, mismo nodo, cada vez — así que GetItem es O(1), no O(tamaño de la tabla).
• Un primario, dos secundarios. Una escritura aterriza en el nodo primario de la partición, que replica a dos secundarios a través de zonas de disponibilidad antes de ser durable.
• Las malas claves derrotan el diseño. Una clave de partición de baja cardinalidad o "caliente" canaliza el tráfico a un nodo — el enrutamiento está bien, tu clave es el problema.

Empieza con el problema que resuelve el enrutamiento

Viniendo de SQL, imaginas un planificador de queries: lee estadísticas, elige un índice, quizás escanea. El coste escala con cuántos datos toca. Ese modelo no encaja con un almacén clave-valor que tiene que responder en milisegundos de un solo dígito a cualquier tamaño.

La respuesta de DynamoDB es hacer de una búsqueda de un solo item una dirección directa, no una búsqueda. La clave de partición no es una columna sobre la que filtras — es la entrada a una función hash que calcula dónde viven físicamente los datos. Sin estadísticas, sin planificador.

Ese es el trato que aceptas cuando te alejas del pensamiento relacional: renuncias a la flexibilidad de queries ad-hoc y obtienes direccionamiento en tiempo constante a cambio.

Conoce el request router

Cuando llega una petición, no va directa al almacenamiento. Golpea un request router — una flota sin estado, escalada horizontalmente, que da la cara por todo el servicio. (Las sesiones "DynamoDB Deep Dive" de AWS re:Invent describen esta flota de front-end.)

El router hace tres cosas y no contiene datos propios:

• Autentica y autoriza la petición contra IAM.
• Hashea la clave de partición para encontrar la partición que la posee.
• Reenvía la petición al nodo de almacenamiento de esa partición.

Como los routers son sin estado, el servicio añade más bajo carga. Ninguno es un cuello de botella y ninguno es un punto único de fallo — la misma propiedad alrededor de la cual el paper de Amazon Dynamo de 2007 construyó el sistema original.

Sigue una lectura a través del router

Toma una tabla de telemetría para una flota de drones. Los items tienen clave por DroneId (clave de partición) y ReadingTs (clave de ordenación), con atributos como BatteryPct y AltitudeM.

Pides la última lectura para un dron:

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

Esto es lo que el router hace con ello. La introducción de abajo traza la petición de arriba abajo — léela como un flujo descendente.

El router hashea DRONE#A19F, lo mapea a la partición que posee esa clave, y reenvía la lectura al nodo de almacenamiento primario de esa partición, que devuelve el item.

La idea clave: el hash apunta a una partición de entre las que tenga la tabla. El router nunca mira otras particiones, así que añadir drones — y particiones — no ralentiza esta búsqueda.

Conoce qué es realmente una partición

Una partición es una unidad de almacenamiento y throughput. Cada una está topada (aproximadamente 10 GB y un trozo fijo de capacidad de lectura/escritura), y DynamoDB divide una partición cuando supera cualquiera de los límites. Cada item con una clave de partición dada vive en la misma partición, que es lo que hace barata una Query sobre una clave de partición.

Cada partición se replica a tres nodos de almacenamiento repartidos a través de zonas de disponibilidad: uno primario y dos secundarios.

Una escritura va al primario, que replica a los secundarios antes de reconocer la durabilidad. Una lectura fuertemente consistente se enruta al primario para que refleje la escritura más reciente. Una lectura eventualmente consistente puede ser servida por un secundario que aún no se ha puesto al día — la mitad del coste, posiblemente obsoleta.

Nombra el footgun: una clave de partición caliente

El enrutamiento es solo tan bueno como tu clave de partición. El hash reparte las claves uniformemente, así que si tus claves tienen alta cardinalidad y tráfico uniforme, la carga se reparte a través de todos los nodos. Rompe cualquiera de las dos propiedades y obtienes una partición caliente.

Digamos que clavas esa telemetría por Region en lugar de DroneId. Ahora cada dron en us-east-1 comparte una clave de partición — así que cada una de sus lecturas y escrituras hashea al mismo nodo. El router está haciendo su trabajo perfectamente; solo has canalizado toda la flota a la capacidad de una sola partición.

No puedes ver al router elegir un nodo, pero sí puedes diseñar claves que enruten bien. Cuando construyes una condición de clave en el constructor de expresiones, la clave de partición que pones a la izquierda de PK = … es el valor exacto que el router hasheará — mantener ese valor de alta cardinalidad es lo que mantiene las lecturas en nodos separados.

Cómo esto se conecta de vuelta a tus patrones de acceso

El enrutamiento de peticiones es el mecanismo que hace las reglas del diseño de tabla única innegociables: modelas alrededor de la clave de partición porque la clave de partición es la dirección. También es por qué una Query le gana a un Scan — una Query golpea una partición a través del router, mientras que un Scan recorre cada partición en secuencia.

Los índices secundarios tienen sus propias particiones y su propio enrutamiento: un GSI se enruta por su propia clave de partición, independiente de la de la tabla base, que es por qué un GSI puede estar caliente aunque la tabla no lo esté.

Próximos pasos

Diseña claves que enruten a muchos nodos, no a uno. Esboza la condición PK = … en el constructor de expresiones para ver exactamente qué valor se hashea, luego descarga DynoTable para ejecutar esas queries contra tus propias tablas y observar qué claves de partición llevan realmente tu tráfico.