Adaptive capacity no DynamoDB
O DynamoDB espalha sua tabela por partições, mas seu tráfego raramente se espalha de forma uniforme. Burst capacity e adaptive capacity são os dois mecanismos automáticos que impedem uma carga de trabalho enviesada de sofrer throttling — até bater em um limite rígido.
O que é a adaptive capacity do DynamoDB?
A adaptive capacity do DynamoDB é um mecanismo automático que desloca throughput não usado em direção a uma para que uma chave enviesada não sofra throttling enquanto o resto da tabela fica ocioso. Combinada com a burst capacity, ela absorve picos e viés sustentado sem custo — mas não consegue empurrar uma única chave além do teto de partição.
- Burst capacity te empresta até 5 minutos (300 segundos) de throughput não usado para atravessar picos curtos. É um buffer, não um recurso que você ajusta.
- Adaptive capacity eleva automaticamente o throughput de uma partição "quente" — puxando da capacidade não usada do resto da sua tabela — para que uma chave enviesada não sofra throttling.
- Ela até isola um item quente em sua própria partição, dando a uma única chave até o teto de partição de 3.000 RCU / 1.000 WCU.
- Ela não é uma licença para ignorar o design de chaves. Passado o teto por partição não sobra de onde tomar emprestado — uma chave realmente quente ainda sofre throttling.
Conheça o teto de partição primeiro
Toda partição é limitada independentemente: 3.000 unidades de leitura e 1.000 unidades de escrita por segundo. Esse limite é físico, não provisionado — ele vale tanto em tabelas provisionadas quanto on-demand. (AWS, Burst and adaptive capacity.)
Vindo do SQL, você raciocina sobre carga total do servidor. No DynamoDB a unidade que sofre throttling é a partição única, e uma chave enviesada pode derreter enquanto a tabela fica 90% ociosa. Essa é a lacuna que ambos os mecanismos existem para fechar.
Burst capacity absorve o pico curto
Sempre que você não usa totalmente o throughput de uma partição, o DynamoDB guarda o restante. Até 300 segundos dessa capacidade não usada são mantidos em reserva, e um pico repentino pode drená-la mais rápido do que sua taxa por segundo normalmente permitiria.
É invisível e automático. Você não consegue dimensioná-la, e o DynamoDB pode gastar parte dela silenciosamente no próprio trabalho de background. Trate-a como uma almofada para tráfego em rajadas — nunca como folga com a qual você pode planejar.
Adaptive capacity impulsiona a hot partition
A burst capacity lida com picos curtos. A adaptive capacity lida com viés sustentado. Quando uma partição roda quente enquanto suas vizinhas ficam ociosas, o DynamoDB desloca throughput em direção à quente — até o total da tabela e o teto de partição.
Digamos que você roda uma tabela de telemetria de frota com chave VEHICLE#<id>
(partição) e TS#<epoch> (sort). Uma van de entrega em uma zona de flash-sale
emite 10× os pings de qualquer outra. A partição dela está quente; as partições das
outras 200 vans ficam quase ociosas.
A adaptive capacity percebe e eleva o throughput dessa única partição, puxando da capacidade não usada das partições frias. Sem config, sem custo, sem aquecimento — desde maio de 2019 o impulso é efetivamente instantâneo. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)
A partição da van quente precisa de 150 WCU mas sua parte igualitária de 100 WCU sofreria throttling; a adaptive capacity toma emprestada a WCU ociosa das partições frias para cobri-la.
Isolamento: quando um único item é o problema
O viés nem sempre é por chave — às vezes um único item está incandescente. Se
tráfego implacável martela um item VEHICLE#HOT, o split-for-heat do DynamoDB
rebalanceia as partições para que o item frequentemente acessado aterrisse sozinho.
Uma vez isolada, a chave desse único item pode puxar o teto de partição completo: 3.000 RCU e 1.000 WCU. Esse é o teto absoluto para uma chave — não há mecanismo acima dele. (AWS, Key range throughput exceeded.)
Uma ressalva que vale fixar: a adaptive capacity não divide uma coleção de itens entre partições quando a tabela tem um Local Secondary Index. Uma LSI amarra a coleção a uma única partição — veja GSI vs LSI para entender por quê.
Quando a adaptive capacity não consegue te salvar
Esta é a armadilha. Ambos os mecanismos movem throughput ao redor; nenhum cria mais do que uma partição fisicamente permite.
| Cenário | Burst | Adaptive | Resultado |
|---|---|---|---|
| Pico curto, tabela com folga | Cobre | — | Sem throttle |
| Viés sustentado, vizinhas frias | — | Impulsiona quente | Sem throttle |
| Um item, < 3K RCU / 1K WCU | — | Isola | Sem throttle |
| Um item, > teto de partição | Drenado rápido | No teto | Throttled — redesign necessário |
| Muitas chaves quentes ao mesmo tempo, tabela no máximo | Drenado rápido | Nada ocioso | Throttled — redesign necessário |
Se uma única chave legitimamente precisa de mais de 1.000 escritas por segundo, nenhum mecanismo automático te resgata — você precisa espalhar a carga por mais chaves.
Write sharding é a correção usual: anexe um sufixo (VEHICLE#HOT#0 … #9)
para que as escritas se distribuam pelas partições, depois junte as leituras de
volta.
Esse fan-in é em si um padrão de acesso para modelar deliberadamente, do mesmo jeito que você planejaria um caminho de query no single-table design — a adaptive capacity compra tempo, não um passe livre no design de chaves.
Veja na sua própria tabela
A adaptive capacity é invisível por design, então você raciocina sobre ela por um
sintoma: quais chaves estão quentes. Quando você constrói o caminho de escrita
fragmentado, o Expression Builder gera a
sintaxe de PutItem e Query para uma chave com sufixo.
Para observar como uma chave de fato se distribui pelos seus dados, baixe o DynoTable e inspecione a distribuição de partições nas suas tabelas reais antes de assumir que a adaptive capacity já cuidou de tudo. Para o lado de leitura do viés, veja Query vs Scan.