DynamoDB pra dev: partition key, GSI e Streams
- ⬜🌐 API Gateway: REST vs HTTP vs WebSocket(AWS Developer Associate (DVA-C02))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Single-Table Design (Rick Houlihan)
Padrão profissional: todos os "objetos" numa tabela. PK/SK overloaded. Ex: PK = USER#123, SK varia por tipo (PROFILE, ORDER#789, ADDRESS#1). Acesso: query por PK retorna tudo relacionado. Access patterns definem schema — design começa por queries, não entidades.
Onde isso entra no exame
Metade das questões de DynamoDB cai em modelagem de chave — partition key de baixa cardinalidade gera hot partition, e essa é a resposta para "throttling mesmo com capacidade sobrando". A outra metade é GSI versus LSI, Query em vez de Scan, e `ConditionExpression` para evitar escrita perdida sob concorrência.
Operações críticas
import { DynamoDB } from '@aws-sdk/client-dynamodb';
// Conditional write — optimistic locking
await ddb.updateItem({
TableName: 'orders',
Key: { id: 'o1' },
UpdateExpression: 'SET #status = :new',
ConditionExpression: '#status = :old AND version = :v',
ExpressionAttributeNames: { '#status': 'status' },
ExpressionAttributeValues: {
':new': 'paid', ':old': 'pending', ':v': 3,
},
});
// TransactWriteItems — ACID em até 100 items
await ddb.transactWriteItems({
TransactItems: [
{ Put: { TableName: 'orders', Item: newOrder } },
{ Update: { TableName: 'users', ... } },
],
});
// BatchGetItem — 100 items em paralelo
await ddb.batchGetItem({ RequestItems: { orders: { Keys: [...] } } });- → hash da chave
- → ordena dentro
- → projeta atributo
- → toda escrita gera evento
- → consome em ordem
- → cache de leitura
- Banco de dados
- Armazenamento
- Analytics
- Compute
Duas frases decidem a maioria das questões: a partition key define a distribuição física (e chave ruim gera hot partition); GSI é assíncrono e tem capacidade própria — e essa capacidade, se estourar, trava a escrita da tabela base.
- A partition key decide tudo. Ela é hasheada para escolher a partição física. Chave com pouca variação (por exemplo, a data de hoje) joga todo o tráfego numa partição — hot partition, throttling com capacidade sobrando na tabela. É o defeito de modelagem nº 1.
- Query vs Scan. Query usa a chave e lê só o necessário. Scan lê a tabela inteira e filtra depois — custa em RCU proporcional ao tamanho, não ao resultado. Scan em tabela grande é sempre a alternativa errada, mesmo quando "funciona".
- GSI é praticamente outra tabela. Outra partition key, capacidade própria, e consistência apenas eventual — não existe leitura fortemente consistente em GSI. Se a capacidade do GSI estoura, a ESCRITA na tabela base é throttled: é a pegadinha mais cruel do DVA.
- LSI só na criação da tabela. Mesma partition key, sort key diferente, consistência forte disponível — mas só pode ser criado junto com a tabela e nunca depois. GSI pode ser adicionado a qualquer momento.
- Streams é o gancho para reagir. Cada escrita gera um evento, retido 24h, ordenado por partição. Lambda consome para manter agregação, replicar, notificar. É como se constrói arquitetura orientada a evento em cima do DynamoDB.
Uma tabela usa a data do dia como partition key para registrar eventos. Em produção, há throttling constante mesmo com capacidade provisionada muito acima do consumo médio. Qual é a causa?
Capacity modes
- On-Demand: escala automático, paga por request, default moderno pra carga variável.
- Provisioned: RCU/WCU fixos, mais barato em carga previsível constante. Auto Scaling possível.
- TTL: attribute como epoch — DynamoDB deleta ±48h após expiry grátis. Ideal pra session, cache, events antigos.
Regra prática: comece On-Demand. Se volume alto e constante por meses, considere migrar pra Provisioned+Auto Scaling pra economizar 30-70%.
Perguntas frequentes
❓ Como escolher a chave de partição?
❓ Índice secundário global ou local?
❓ Para que servem os fluxos de mudança da tabela?
Fixando
Qual afirmação sobre GSI (Global Secondary Index) é correta?
Uma aplicação precisa reagir a cada alteração numa tabela DynamoDB para manter um agregado atualizado. Qual mecanismo?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…