Database Design Mistakes I Made So You Don't Have To \u2014 TXT1.ai

Três anos atrás, eu vi o banco de dados da nossa startup parar às 2:47 AM na Black Friday. Tínhamos 50.000 usuários simultâneos, $2 milhões em transações pendentes e uma consulta que estava levando 45 segundos para retornar a disponibilidade dos produtos. Nosso CTO estava gritando no Slack. Nossos investidores estavam ligando. E eu estava encarando um esquema que desenhei seis meses antes, percebendo que cada decisão “brilhante” que tomei agora estava nos custando cerca de $8.000 por minuto em receita perdida.

Eu sou Marcus Chen, e passei os últimos doze anos como arquiteto de banco de dados, trabalhando com todos, desde startups de SaaS até empresas da Fortune 500. Eu desenhei esquemas para sistemas que lidavam com 500 milhões de transações diárias, otimizei consultas que reduziram 200ms em caminhos críticos e sim—fiz praticamente todos os erros de design de banco de dados que existem. Aquele incidente da Black Friday? Ele me ensinou mais sobre design de banco de dados do que todo o meu curso de ciência da computação.

Hoje, sou o Arquiteto Principal de Banco de Dados na TXT1.ai, onde processamos mais de 3 bilhões de mensagens de texto anualmente em nossa plataforma de comunicação alimentada por IA. Mas cheguei até aqui falhando para frente, e quero compartilhar as lições caras que aprendi para que você possa pular os ataques de pânico às 2 AM e as ligações de investidores irritados.

O Desastre do "Eu Vou Usar UUIDs em Todo Lugar"

Deixe-me começar com o que chamo de meu erro de $40.000. Em 2019, eu estava projetando um sistema de gerenciamento de relacionamento com o cliente para uma empresa de e-commerce de médio porte. Eu tinha acabado de ler um post de blog sobre como UUIDs eram a forma “moderna” de lidar com chaves primárias—nada mais de inteiros autoincrementais, nada mais de exposição sequencial de IDs, perfeito para sistemas distribuídos. Eu estava convencido.

Então, eu fiz de cada chave primária no sistema um UUID. Tabela de usuários? UUID. Tabela de pedidos? UUID. Itens de pedido? Você adivinhou—UUID. Eu me senti como um gênio. O esquema parecia limpo, não havia vulnerabilidades de IDs sequenciais, e eu poderia gerar IDs do lado do cliente, se necessário. O que poderia dar errado?

Tudo. Absolutamente tudo deu errado.

Em seis meses, o tamanho do nosso banco de dados havia crescido para 340GB quando deveria estar em torno de 180GB. O desempenho das consultas estava se deteriorando semana após semana. Nossos tamanhos de índice eram massivos—o índice da tabela de pedidos por si só tinha 12GB. Junções entre pedidos e itens de linha que deveriam levar 50ms estavam levando 800ms. O banco de dados estava gastando enormes quantidades de tempo em I/O de disco, e nossos custos no AWS RDS quase dobraram.

Aqui está o que aprendi da maneira difícil: UUIDs têm 128 bits (16 bytes) em comparação com um inteiro de 4 bytes ou bigint de 8 bytes. Isso é 4x o armazenamento para cada chave primária. Mas o verdadeiro problema não é o armazenamento—é a fragmentação de índice. UUIDs são aleatórios, o que significa que cada inserção causa gravações aleatórias em seus índices B-tree. Com inteiros sequenciais, novas linhas são adicionadas ao final do índice. Com UUIDs, o banco de dados está constantemente reequilibrando toda a estrutura do índice.

Medimos o impacto: inserir 100.000 linhas com IDs inteiros levou 8 segundos. A mesma operação com UUIDs levou 34 segundos. Essa é uma penalização de desempenho de 4,25x apenas pela escolha da chave primária. Quando você está processando 50.000 pedidos por dia, isso se acumula rapidamente.

A correção nos custou três semanas de tempo de desenvolvimento e exigiu uma migração cuidadosamente orquestrada durante uma janela de manutenção. Nós mudamos para chaves primárias bigint para tabelas de alto volume e mantivemos UUIDs apenas para tabelas onde realmente precisávamos de identificadores globalmente únicos em sistemas distribuídos—que se provaram ser exatamente duas tabelas em quarenta e sete.

Minha regra agora: Use inteiros autoincrementais ou bigints para chaves primárias, a menos que você tenha uma razão específica e documentada para usar UUIDs. E “parece mais moderno” não é uma razão documentada.

Normalização Prematura: Quando a Terceira Forma Normal se Torna Seu Inimigo

Recém-saído da universidade, eu estava obcecado por normalização. Tinha decorado todas as formas normais, podia recitar as regras de Codd enquanto dormia e acreditava que um banco de dados devidamente normalizado era o auge da excelência em design. Então, quando projetei meu primeiro sistema de produção—uma plataforma de gerenciamento de conteúdo—eu normalizei tudo até a terceira forma normal e além.

"Toda decisão 'brilhante' de banco de dados que você toma hoje é uma crise em potencial às 2 AM seis meses depois. Projete para o sistema que você terá, não para o sistema que você deseja."

Eu tinha uma tabela de usuários, uma tabela user_addresses (porque os usuários poderiam ter vários endereços), uma tabela user_phone_numbers (múltiplos telefones!), uma tabela user_preferences, uma tabela user_settings e uma tabela user_metadata. Carregar o perfil de um único usuário exigia junção de seis tabelas. Eu estava tão orgulhoso de quão "limpo" tudo parecia.

Então nós lançamos. A página do perfil do usuário— a página mais acessada em toda a aplicação—estava levando 1,2 segundos para carregar. Estávamos fazendo seis junções para cada única visualização de página, e com 10.000 usuários ativos diários, isso significava 60.000 junções por dia apenas para visualizações de perfil. A CPU do banco de dados estava constantemente acima de 70%.

O chamado de atenção veio quando nosso desenvolvedor líder me puxou de lado e me mostrou o plano de execução da consulta. "Marcus," ele disse, "estamos juntando seis tabelas para exibir o nome, e-mail e telefone de um usuário. Isso é insano." Ele estava certo. Eu tinha otimizado para pureza teórica em vez de desempenho prático.

Desnormalizamos estrategicamente. O endereço principal do usuário voltou para a tabela de usuários. O seu número de telefone principal? A mesma coisa. Mantivemos as tabelas separadas para endereços e números de telefone adicionais, mas 94% de nossos usuários tinham apenas um de cada. Essa única mudança reduziu nosso tempo médio de consulta da página de perfil de 1,2 segundos para 180ms—uma melhoria de 85%.

Aqui está o que aprendi: A normalização é uma ferramenta, não uma religião. A terceira forma normal é um ótimo ponto de partida, mas o desempenho no mundo real frequentemente requer denormalização estratégica. Agora eu sigo o que chamo de "regra de denormalização 80/20"—se 80% das consultas precisarem de dados de várias tabelas, esses dados provavelmente pertencem a uma única tabela. Eu medi padrões de consulta em produção e denormalizo com base no uso real, não na pureza teórica.

A chave é saber quando denormalizar. Tabelas de leitura alta e escrita baixa são candidatas perfeitas. Perfis de usuários, catálogos de produtos, dados de configuração—todos esses são ótimos lugares para denormalizar. Tabelas de transação com altos volumes de escrita? Mantenha-as normalizadas para evitar anomalias de atualização.

O Pesadelo do NULL: Quando Opcional se Torna Impossível

Eu costumava adorar colunas que aceitavam NULL. Elas pareciam tão flexíveis, tão acolhedoras. Um usuário pode não ter um nome do meio? Deixe como NULL. Um pedido pode não ter um código de desconto? Nulo. Um produto pode não ter um peso? Você entendeu a ideia.

B