Como o Roteamento de Requisições do DynamoDB Funciona

Toda leitura ou escrita que você envia atinge primeiro uma frota de request routers stateless. Um router faz hash da sua partition key, mapeia o hash para o nó de armazenamento que é dono dos dados daquela chave, e encaminha a requisição para lá. Esse único salto é por que uma busca de chave custa o mesmo quer a tabela guarde mil itens ou um bilhão.

Como funciona o roteamento de requisições do DynamoDB?

O DynamoDB roteia cada requisição por uma frota de request routers stateless que faz hash da sua partition key, mapeia o hash para o único nó de armazenamento dono daquela partição e encaminha a leitura ou escrita até lá. O roteamento é uma função pura do hash da chave, então uma busca custa o mesmo quer a tabela tenha mil itens ou um bilhão.

• O request router é a porta da frente. É uma frota stateless que pega sua requisição, faz hash da partition key e a roteia para o nó de armazenamento que guarda aquela partição — sem varredura, sem precisar conhecer a tabela inteira.
• A partition key decide tudo. O roteamento é uma função pura do hash da partition key. Mesma chave, mesmo nó, toda vez — então GetItem é O(1), não O(tamanho da tabela).
• Um primário, dois secundários. Uma escrita aterrissa no nó primário da partição, que replica para dois secundários entre Availability Zones antes de ser durável.
• Chaves ruins derrotam o design. Uma partition key de baixa cardinalidade ou "quente" funila o tráfego para um nó — o roteamento está ok, sua chave é o problema.

Comece pelo problema que o roteamento resolve

Vindo do SQL, você imagina um query planner: ele lê estatísticas, escolhe um índice, talvez varre. O custo escala com quanto dado ele toca. Esse modelo não encaixa em um key-value store que precisa responder em milissegundos de um dígito em qualquer tamanho.

A resposta do DynamoDB é tornar a busca de um item único um endereço direto, não uma busca. A partition key não é uma coluna na qual você filtra — é a entrada para uma função de hash que computa onde o dado fisicamente vive. Sem estatísticas, sem planner.

Essa é a troca que você aceita ao sair do pensamento relacional: você abre mão da flexibilidade de query ad-hoc e ganha endereçamento em tempo constante em troca.

Conheça o request router

Quando uma requisição chega, ela não vai direto para o armazenamento. Ela atinge um request router — uma frota stateless e horizontalmente escalada que fica na frente do serviço inteiro. (As sessões AWS re:Invent "DynamoDB Deep Dive" descrevem essa frota de front-end.)

O router faz três coisas e não guarda dado próprio nenhum:

• Autentica e autoriza a requisição contra o IAM.
• Faz hash da partition key para encontrar a partição que é dona dela.
• Encaminha a requisição para o nó de armazenamento daquela partição.

Como os routers são stateless, o serviço adiciona mais deles sob carga. Nenhum deles é um gargalo e nenhum é um ponto único de falha — a mesma propriedade em torno da qual o paper Amazon Dynamo de 2007 construiu o sistema original.

Acompanhe uma leitura pelo router

Pegue uma tabela de telemetria para uma frota de drones. Os itens têm chave por DroneId (partition key) e ReadingTs (sort key), com atributos como BatteryPct e AltitudeM.

Você pede a leitura mais recente de um drone:

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

Aqui está o que o router faz com isso. A introdução abaixo traça a requisição de cima para baixo — leia como um fluxo único para baixo.

O router faz hash de DRONE#A19F, o mapeia para a partição que é dona daquela chave, e encaminha a leitura para o nó de armazenamento primário daquela partição, que retorna o item.

O insight-chave: o hash aponta para uma partição dentre quantas a tabela tiver. O router nunca olha para outras partições, então adicionar drones — e partições — não desacelera essa busca.

Saiba o que uma partição de fato é

Uma partição é uma unidade de armazenamento e throughput. Cada uma é limitada (aproximadamente 10 GB e uma fatia fixa de capacidade de leitura/escrita), e o DynamoDB divide uma partição quando ela ultrapassa qualquer um dos limites. Todo item com uma dada partition key vive na mesma partição, que é o que torna um Query sobre uma partition key barato.

Cada partição é replicada para três nós de armazenamento espalhados por Availability Zones: um primário e dois secundários.

Uma escrita vai para o primário, que replica para os secundários antes de confirmar a durabilidade. Uma leitura fortemente consistente é roteada para o primário para refletir a última escrita. Uma leitura eventualmente consistente pode ser servida por um secundário que ainda não alcançou — metade do custo, possivelmente defasada.

Nomeie o footgun: uma hot partition key

O roteamento é só tão bom quanto sua partition key. O hash espalha as chaves uniformemente, então se suas chaves têm alta cardinalidade e tráfego uniforme, a carga se espalha por todos os nós. Quebre qualquer uma dessas propriedades e você ganha uma hot partition.

Digamos que você dá chave a essa telemetria por Region em vez de DroneId. Agora todo drone em us-east-1 compartilha uma partition key — então cada uma de suas leituras e escritas faz hash para o mesmo nó. O router está fazendo seu trabalho perfeitamente; você só funilou a frota inteira para a capacidade de uma única partição.

Você não consegue ver o router escolher um nó, mas você consegue projetar chaves que roteiam bem. Quando você monta uma key condition no Expression Builder, a partition key que você coloca à esquerda de PK = … é o valor exato que o router vai hashear — manter esse valor de alta cardinalidade é o que mantém as leituras em nós separados.

Como isso se conecta de volta aos seus padrões de acesso

O roteamento de requisições é o mecanismo que torna as regras do single-table design inegociáveis: você modela em torno da partition key porque a partition key é o endereço. É também por que um Query vence um Scan — um Query atinge uma partição pelo router, enquanto um Scan percorre toda partição em sequência.

Índices secundários ganham suas próprias partições e seu próprio roteamento: uma GSI é roteada pela própria partition key, independente da tabela base, que é por que uma GSI pode estar quente mesmo quando a tabela não está.

Próximos passos

Projete chaves que roteiam para muitos nós, não um. Esboce a condição PK = … no Expression Builder para ver exatamente qual valor é hasheado, depois baixe o DynoTable para rodar essas queries contra suas próprias tabelas e observar quais partition keys de fato carregam seu tráfego.