Não existem soluções, só trade-offs: as sacadas do Capítulo 1 de DDIA · willybr

"There are no solutions, only trade-offs." É a primeira frase de Designing Data-Intensive Applications (DDIA) e foi também o ponto de partida da nossa discussão no Clube do Livro da comunidade Craft Code Club. Juntei aqui as sacadas que mais renderam conversa, com foco no que dá pra levar pro seu dia a dia.

(Tem vídeo da discussão completa e convite pra participar dos próximos encontros lá no final.)

1. O relatório que derruba o sistema (OLTP vs OLAP)

O exemplo mais real possível: a equipe inteira clica em "gerar relatório" e o sistema fica lento. Acontece quando a gente mistura carga transacional (OLTP) e analítica (OLAP) na mesma base. São demandas opostas: uma quer muita escrita e leitura pontual com baixa latência; a outra varre o mês inteiro para agregar e tolera esperar.

A sacada prática que o livro pula: você não precisa pular direto pra um data warehouse e pipelines de ETL. Quase sempre existe um caminho do meio que segura as pontas por muito tempo: uma read replica pra rodar relatório fora do banco principal, ou views materializadas e agregações pré-computadas no próprio banco.

2. Categorize seus dados: system of record vs derivado

Uma das melhores definições do capítulo separa tudo em dois baldes:

System of record: a fonte da verdade, o dono do dado.
Dado derivado: tudo que dá pra reconstruir a partir do system of record. Se perder, você regenera.

O cache é o exemplo canônico de dado derivado. Parece óbvio, mas categorizar cada dado assim muda o design: você passa a saber exatamente o que pode jogar fora e o que precisa proteger com a vida. E lembre: um banco não é "de registro" ou "derivado" por natureza, depende de como você usa.

3. Cuidado quando o analítico vira operacional

O Data Lake parece perfeito: tudo a um SELECT de distância. Aí alguém começa a usar o warehouse como base operacional, em tempo real, e ele vira a fonte da verdade da empresa inteira. As consultas pesadas passam a competir com a aplicação, e é o problema original refeito ao contrário.

Geralmente a raiz é uma divisão errada de microsserviços: o serviço não tem os dados que deveria ter, ninguém quer duplicar, e quando você vê não tem microsserviço, tem um monolito distribuído com o warehouse fazendo papel de banco.

4. Você já tem um sistema distribuído (basta a rede)

Não precisa de microsserviço nenhum: no momento em que aplicação e banco conversam por rede, ou que o usuário acessa seu sistema por rede, você já tem um sistema distribuído, sujeito a falha de partição (teorema CAP). A internet é tão bem feita que a gente trata a rede como algo natural, mas por baixo tem pacote falhando e retry rolando o tempo todo.

A consequência: adotar "distribuído" é comprar um pacote de problemas (retry, timeout, tratamento de falha) que você não tem quando a memória vai direto de um processo pro outro. Familiaridade não é o mesmo que simplicidade.

5. Um nó só, às vezes, ganha

Contraintuitivo: uma única máquina pode ser bem mais rápida que vinte horizontais. Em baixíssima latência (trading, por exemplo), um single thread pode bater o multi thread, porque coordenar paralelismo custa caro. E escala vertical tem teto: teve relato de uma máquina que, ao sair de 64 GB para 120 GB de RAM, ficou mais lenta por depender de swap e upgrade de todos os demais componentes. Escala não é só "quanto", é "para quê".

6. Microsserviço escala TIME, não tecnologia

Talvez o ponto que mais rendeu: microsserviços foram criados para escalar times, não para resolver problema técnico. É problema de gente resolvido de forma técnica.

O termômetro de maturidade: se, pra entregar uma feature no seu serviço, você precisa alinhar roadmap com quatro ou cinco outros times, a independência que justificava os microsserviços já evaporou. E distribuído sem resiliência é só um monolito distribuído: se cair um serviço e cair tudo, você só aumentou sua superfície de falha.

Bônus: privacidade virou problema de arquitetura

Muitos sistemas foram pensados como imutáveis (eventos, logs, Kafka), aí veio a LGPD com o direito ao esquecimento. Como apagar de um log imutável? Uma saída elegante é o crypto-shredding: uma chave de criptografia por usuário; quando ele pede pra sair, você apaga a chave e o dado vira lixo irrecuperável. E tem o princípio da minimização: o melhor dado pessoal é o que você decidiu não guardar.

O fio que costura tudo

Trade-off é você saber o que está pagando. Se em alguma decisão você só enxerga vantagens, provavelmente ainda não achou o custo escondido. Engenharia sênior não é evitar o atalho, é escolher o atalho sabendo o preço dele.

Esse resumo nasceu de uma conversa de quase duas horas no nosso Clube do Livro, onde a cada quinze dias a comunidade discute um capítulo de DDIA. Sem aula, sem palestra, só gente que vive esses problemas trocando ideia (e cicatrizes de produção).

🎥 Assista à discussão completa no YouTube:
https://www.youtube.com/watch?v=53TFZSe-IGw

📚 Participe do Clube do Livro (DDIA):
https://craftcodeclub.io/book-club/designing-data-intensive-applications

📅 Próximo encontro (bora participar?):
Book Club DDIA, Capítulo 2: Definindo Requisitos Não Funcionais
🗓️ 29 de junho de 2026, das 20:00 às 21:30, online.

Garanta sua presença nos eventos da comunidade:
https://craftcodeclub.io/events