Write Ahead {B}Log

Quando falamos em bancos de dados, quase todo mundo começa pelo mesmo lugar: tabelas, colunas, índices e SQL. Durante anos, essa foi a base da maioria dos sistemas críticos. Mas conforme aplicações cresceram, não só em volume de dados, mas em volume de acessos simultâneos, picos imprevisíveis e exigência de disponibilidade quase absoluta, esse modelo começou a mostrar seus limites.

É exatamente nesse contexto que surge o Amazon DynamoDB.

Mais do que “um banco NoSQL”, o DynamoDB foi desenhado com um objetivo muito claro: entregar latência previsível e baixa, independentemente da escala. Não importa se sua aplicação faz 10 requisições por segundo ou centenas de milhares de forma sustentada. A promessa é a mesma: resposta rápida, estável e altamente disponível sem você precisar gerenciar servidores, discos, réplicas ou failover.

Essa promessa parece ousada. E é justamente por isso que entender como o DynamoDB funciona por dentro é tão importante quanto saber usar sua API.

O problema que o DynamoDB veio resolver

Em sistemas tradicionais, crescer costuma significar “escapar do confortável”. Mais conexões abertas, mais lock, mais contenção, tuning constante, índices brigando entre si, planos de execução que mudam conforme o volume cresce. Muitas vezes, o gargalo não é o dado em si, mas o esforço para mantê-lo disponível sob carga.

O DynamoDB nasce em outro paradigma. Ele assume que:

• aplicações modernas precisam estar disponíveis o tempo todo
• picos de tráfego não são exceção, são regra
• falhas de hardware não podem derrubar sistemas
• a latência precisa ser previsível, não apenas “boa em média”

Por isso, ele é amplamente usado em serviços como autenticação, controle de sessões, inventário, catálogos, carrinhos de compra, metadados de sistemas distribuídos. Inclusive,️ grande parte da própria AWS roda sobre DynamoDB.

Aqui, o banco não é apenas um repositório de dados — ele é parte do alicerce da aplicação.

Totalmente gerenciado (de verdade)

Quando dizemos que o DynamoDB é totalmente gerenciado, não estamos falando apenas de “não instalar patch”. Estamos falando de uma arquitetura global, distribuída, multi-tenant e altamente paralela, onde:

• os dados são automaticamente particionados
• o serviço escala horizontalmente sem intervenção
• falhas de nós individuais são absorvidas sem impacto perceptível
• criptografia em repouso e em trânsito já faz parte do fluxo
• múltiplas zonas de disponibilidade trabalham juntas

Você não escolhe instância, não ajusta memória, não define RAID, não se preocupa com replicação. Você define como quer acessar os dados e o serviço cuida do resto.

Essa troca é fundamental:
menos controle operacional, mais responsabilidade no desenho do acesso aos dados.

Latência previsível em qualquer escala

Um dos pontos mais difíceis de explicar para quem vem do mundo relacional é o conceito de latência previsível. Não é apenas “rápido”, mas consistentemente rápido.

Em muitos bancos, quando o tráfego cresce, a latência cresce junto. No DynamoDB, a arquitetura é construída para que isso não aconteça, desde que você respeite o modelo de acesso esperado.

Na prática, isso significa que:

• não existe “consulta que degrada porque a tabela cresceu”
• não existe “índice que começa a doer depois de alguns milhões de linhas”
• não existe “plano de execução surpresa”

O custo dessa previsibilidade é simples: o DynamoDB não tenta adivinhar como você quer acessar seus dados, você precisa dizer isso explicitamente.

Key-value e document store: o que isso significa na prática

O DynamoDB é, ao mesmo tempo, um key-value store e um document store.

Cada registro é chamado de item. Um item é identificado unicamente por sua chave primária e pode conter atributos simples (strings, números) ou estruturas mais complexas (listas, mapas, conjuntos).

Não existe schema imposto pelo banco além da chave primária. A forma do dado é responsabilidade da aplicação. Isso muda completamente a lógica de trabalho de um DBA:

• o schema deixa de ser “algo que o banco garante”
• validação passa a viver no código
• consistência estrutural vira um contrato da aplicação
• evolução de schema acontece de forma incremental

Esse ponto costuma assustar no início, mas é também o que dá flexibilidade para evoluir sistemas sem paradas longas ou migrações traumáticas.

Chave primária: o coração do DynamoDB

Tudo no DynamoDB gira em torno da chave primária. Ao criar uma tabela, você escolhe entre dois tipos:

• chave simples: apenas partition key
• chave composta: partition key + sort key

A partition key define onde o dado será armazenado fisicamente. É ela que o serviço usa para distribuir dados entre partições internas.

A sort key, quando existe, organiza itens relacionados dentro da mesma partição.

Esse detalhe é crítico: itens que compartilham a mesma partition key ficam fisicamente próximos, permitindo leituras eficientes de conjuntos relacionados.

Não existe “WHERE qualquer_coluna = valor”. Existe “me diga exatamente onde procurar”, e é isso que garante a performance previsível.

Como o DynamoDB escala por dentro

Internamente, o DynamoDB usa particionamento baseado em hash. Quando um item é escrito, o valor da partition key passa por uma função de hash. Esse hash determina em qual partição física o dado vai cair. À medida que a tabela cresce ou o volume de tráfego aumenta, novas partições são adicionadas automaticamente.

O ponto-chave é este: o custo de descobrir onde o dado está é sempre constante, não importa o tamanho da tabela.

É por isso que o acesso direto por chave é tão eficiente, mesmo em tabelas gigantescas.

API explícita: você escolhe o caminho

Diferente de bancos SQL, o DynamoDB não tem um otimizador que decide como buscar seus dados.

Ele oferece operações explícitas:

• leitura e escrita de item único
• consultas baseadas em partition key (com variações na sort key)
• varreduras completas (que existem, mas devem ser usadas com cuidado)

Cada chamada representa um acesso direto e controlado ao armazenamento. Esse design força uma mudança de mentalidade importante: no DynamoDB, você é o planejador de acesso.

Por que entender a arquitetura importa mais do que decorar comandos

Muitos problemas atribuídos ao DynamoDB não são bugs. São consequências de não entender como o serviço funciona internamente.

Distribuição desigual de carga, throttling inesperado, custos altos ou latência inconsistente quase sempre têm relação com:

• baixa cardinalidade de chaves
• padrões de escrita concentrados
• uso inadequado de índices
• conexões mal gerenciadas na aplicação

Quando você entende como o DynamoDB roteia requisições, como ele cacheia metadados e como ele espera que a carga seja distribuída, esses problemas deixam de ser misteriosos e passam a ser decisões de design corrigíveis.

Onde esse conhecimento começa a virar modelagem

Tudo que vimos até aqui prepara o terreno para a parte mais importante: modelar dados para acesso, não para armazenamento. É aqui que entram conceitos como:

• chaves compostas bem desenhadas
• padrões de acesso claros
• uso consciente de índices secundários
• evolução de schema sem dor
• e, mais recentemente, chaves compostas por múltiplos atributos

Mas isso já é assunto para o próximo capítulo.