DynamoDB Streams

O DynamoDB Streams é um log de change-data-capture: toda inserção, atualização e deleção em uma tabela é capturada, em ordem, como um fluxo de registros aos quais você pode reagir. É como você transforma uma tabela em uma fonte de eventos sem fazer polling.

No cenário do log de auditoria, você quer reagir no instante em que um evento sensível chega — disparar um alerta quando alguém exporta uma fatura ou concede um papel de admin — sem fazer scan da tabela em um cronômetro. O Streams é o lado de push disso.

Como o DynamoDB Streams funciona?

O DynamoDB Streams captura toda inserção, atualização e deleção em uma tabela como um log ordenado por tempo e desduplicado de registros, retido por até 24 horas. Você escolhe o que cada registro carrega com o StreamViewType (apenas as chaves, a nova imagem, a imagem antiga ou ambas), e depois consome o stream com um trigger do Lambda para reagir a mudanças nos itens sem fazer polling.

• O Streams captura mudanças no nível do item como um log ordenado por tempo e desduplicado, retido por até 24 horas.
• Você escolhe o que cada registro carrega via StreamViewType: apenas as chaves, a nova imagem, a imagem antiga, ou ambas a antiga e a nova.
• Os registros são ordenados dentro de uma chave de partição, e um stream é fragmentado da mesma forma que a tabela.
• O consumidor nativo é o Lambda — um trigger que roda por lote de novos registros, com o Kinesis Data Streams como alternativa para um fan-out mais rico.

O problema: reagir sem fazer polling

Você precisa de "me avise quando um evento role.granted for escrito". A abordagem ingênua é um job agendado que faz scan em busca de novos eventos a cada minuto — o que lê a partição recente inteira toda vez, custa capacidade e está sempre pelo menos um minuto atrasado.

O que você realmente quer é um push: o DynamoDB te avisa no momento em que um item muda. É exatamente o que o Streams fornece, com o registro da mudança entregue ao seu código em vez de você ir atrás dele.

Como o Streams funciona

Segundo a documentação da AWS, o DynamoDB Streams armazena "um log desduplicado e ordenado por tempo de mudanças por até 24 horas" com integração nativa com o Lambda (change data capture para DynamoDB). Cada registro descreve uma modificação no nível do item.

Quando você ativa um stream, escolhe um StreamViewType, que controla quanto do item alterado cada registro carrega:

Os registros são ordenados dentro de cada chave de partição e o stream é fragmentado seguindo a mesma estrutura de partições que a tabela. A retenção é de 24 horas — o Streams é um buffer de reação, não um histórico permanente. Para histórico durável você armazena os próprios eventos (que é exatamente o que a nossa tabela de log de auditoria já é).

O consumidor nativo é um trigger Lambda: o DynamoDB invoca sua função com um lote de novos registros do stream conforme eles chegam.

Um exemplo prático: alertar em eventos de auditoria sensíveis

A tabela de log de auditoria recebe um stream com NEW_IMAGE, então cada registro carrega o novo evento completo. Um Lambda consome o lote e encaminha apenas os registros que importam:

A função nunca toca a tabela — ela reage puramente ao que o stream entrega. Sem polling, sem scan, e o alerta dispara segundos após a escrita. Como os registros são ordenados por chave de partição, todos os eventos de um tenant chegam na ordem em que foram escritos.

Essa também é a forma padrão de manter uma cópia downstream: um consumidor do stream pode projetar cada evento no OpenSearch para busca textual de auditoria, ou agregar contagens — tudo derivado do mesmo log de mudanças.

Faça no DynoTable

Antes de conectar um consumidor de stream, você precisa saber o formato exato do item que seu Lambda vai receber — quais atributos existem, como mapas e listas aninhados se parecem, o que um registro NEW_IMAGE vai conter de fato.

Para converter um item de amostra entre JSON puro e o formato attribute-value que um registro de stream usa, o Conversor de DynamoDB JSON faz isso no seu navegador. E no DynoTable, você pode inspecionar o item completo — inclusive na sua forma DynamoDB-JSON — para modelar o registro NEW_IMAGE contra dados reais em vez de chutar o formato dos campos.

Se você está testando um consumidor localmente, rode a tabela contra o DynamoDB Local e inspecione-a da mesma forma — veja conectar ao DynamoDB Local.

Armadilhas e próximos passos

• 24 horas não é um backlog. Se o seu consumidor ficar fora do ar por um dia, os registros expiram e somem. O Streams é para reação quase em tempo real, não replay durável — mantenha os próprios eventos para histórico.
• Escolha o menor StreamViewType de que você precisa. O NEW_AND_OLD_IMAGES dobra o payload; se você só precisa da chave para ir reler o item, o KEYS_ONLY é mais barato.
• A ordenação é por chave de partição, não global. Eventos de dois tenants diferentes não têm garantia de ordenação entre si — apenas dentro da partição de um tenant.
• As deleções por TTL aparecem como registros de stream com o marcador de atributo de sistema, que é como você arquiva itens que estão expirando — veja DynamoDB TTL.

O Streams transforma o log de auditoria em uma fonte de eventos. A próxima preocupação operacional é o extremo oposto da vida de um item — expirar eventos antigos automaticamente com DynamoDB TTL.

Baixe o DynoTable para inspecionar o formato exato do item que seu consumidor de stream vai receber antes de escrever uma linha de código Lambda.