Este episódio é a versão em áudio de Engenharia de Cobrança: Modelando Dados no DynamoDB, Gerado por IA.
Obrigado por ler Crônicas de um Programador Pragmático! Inscreva-se gratuitamente para receber novas publicações e apoiar meu trabalho.
Segunda-feira, 8h40. O canal de atendimento ao cliente está pegando fogo… o clássico pesadelo matinal de qualquer operação! Será que tudo está perdido? Não… por enquanto não… 👀
A conversa percorre as escolhas que separam um modelo que responde o negócio de um que só grava entidade: por que a lista de perguntas vem antes da tabela, por que dias de atraso nunca deveriam estar gravados, por que CPF não pode ir na chave de partição, e por que um índice de agenda sobrecarregado é capaz de impedir o registro de um pagamento às 00h07.
No episódio:
A reunião que ninguém quer marcar — e por que o ORM não pode representar o negócio nela
Grave o fato, derive o estado: a diferença entre a data de nascimento e a idade
Num BaaS, a chave de partição é uma decisão de isolamento
Índice esparso: sair da régua é arrancar o post-it da geladeira
O engarrafamento do estacionamento que tranca a rua da ambulância
Onde o dinheiro realmente vaza — e por que não é armazenamento
O artigo completo traz os exemplos o catálogo dos doze padrões de acesso, a anatomia da chave passo a passo e a conta de custo dos dois modelos lado a lado: Engenharia de Cobrança: Modelando Dados no DynamoDB
Se você opera cobrança, crédito ou pagamentos em DynamoDB, me conta nos comentários: qual foi a pergunta que a sua tabela não soube responder?
