Lições do Livro Designing Data-Intensive Applications

Depois de alguns meses de leitura, finalmente terminei Designing Data-Intensive Applications. É um daqueles livros que muita gente recomenda como leitura essencial para quem trabalha com backend, arquitetura ou sistemas distribuídos. Depois de concluir a leitura, entendo melhor o motivo: ele não é apenas um livro sobre bancos de dados, filas, caches ou processamento distribuído. É um livro sobre como pensar melhor a respeito dos sistemas que construímos quando os dados deixam de ser um detalhe de implementação e passam a ser parte central do produto.

Uma das ideias que mais me chamou atenção é simples, mas muda a forma de olhar para software: grande parte das aplicações que desenvolvemos hoje existe para receber, armazenar, transformar, consultar ou distribuir dados. Isso vale para APIs, aplicações desktop, serviços em background, pipelines de processamento, ferramentas internas e produtos SaaS. Por trás de interfaces e regras de negócio, quase sempre existe algum fluxo de dados que precisa continuar correto, disponível e compreensível enquanto o sistema cresce.

O livro parte dessa observação e mostra por que trabalhar com dados em escala exige mais do que escolher uma tecnologia popular. Conforme o volume de dados, o número de usuários e a quantidade de integrações aumentam, surgem decisões difíceis sobre confiabilidade, escalabilidade, consistência, desempenho, evolução de schema e tolerância a falhas.

A primeira parte do livro constrói a base conceitual. Ela apresenta termos e ideias que aparecem o tempo todo em discussões sobre sistemas de dados: confiabilidade, escalabilidade, manutenibilidade, modelos de dados, linguagens de consulta, índices, armazenamento e evolução de formatos. Um ponto que parece pequeno, mas que muda a conversa sobre performance, é a explicação sobre métricas como percentis. Em vez de olhar apenas para média de latência, o livro mostra por que p95, p99 e outras medidas de cauda são importantes quando queremos entender a experiência real dos usuários.

Essa parte também amplia a discussão sobre bancos relacionais e não relacionais. Em vez de reduzir a decisão a “Postgres ou MongoDB”, o livro mostra que cada modelo de dados carrega vantagens, limitações e pressupostos diferentes. A pergunta deixa de ser “qual tecnologia está na moda?” e passa a ser “qual modelo representa melhor os acessos, relacionamentos, consultas e mudanças que este sistema precisa suportar?”.

A segunda parte mergulha nos problemas de dados distribuídos. Aqui entram temas como replicação, particionamento, transações, consistência, consenso e falhas parciais. Foi a parte mais densa da leitura para mim. Em vários momentos, o livro apresenta cenários muito específicos: atrasos de replicação, conflitos de escrita, leituras inconsistentes, falhas de rede, relógios não confiáveis, particionamento de dados e coordenação entre nós. É uma quantidade grande de informação, e algumas seções exigem leitura mais lenta.

Mesmo assim, essa densidade é justamente o que torna a leitura valiosa. Muitos problemas que parecem acidentes isolados em uma empresa aparecem no livro como padrões conhecidos de sistemas distribuídos. Isso muda a forma de encarar incidentes e decisões arquiteturais. Alguns comportamentos não são “bugs estranhos” de uma ferramenta específica; são consequências naturais de tentar manter dados corretos e disponíveis em ambientes onde máquinas, redes e processos podem falhar de formas diferentes.

A terceira parte conecta essas fundações ao que fazemos depois que os dados entram no domínio da aplicação. O livro discute processamento em lote, processamento por streams, dados derivados e formas de manter diferentes visões de um mesmo conjunto de informações sincronizadas. Essa parte me ajudou a pensar além do banco de dados principal. Em sistemas reais, os dados quase sempre aparecem em múltiplos lugares: índices de busca, caches, filas, data warehouses, projeções, relatórios, integrações externas e modelos analíticos. O desafio não é apenas gravar dados, mas entender como essas cópias são produzidas, atualizadas e reconciliadas.

No fim, Designing Data-Intensive Applications me trouxe uma visão mais ampla sobre o que significa escalar uma aplicação. Escalar não é apenas suportar mais usuários ou mais requisições por segundo. Também é conseguir evoluir o sistema sem perder clareza, manter dados consistentes o suficiente para o negócio, entender os trade-offs de cada decisão e aceitar que não existe arquitetura perfeita fora de um contexto específico.

Não acho que seja uma leitura simples para quem está no início da carreira. O livro cobre muitos conceitos, e parte do valor aparece com mais força quando você já passou por problemas reais: uma query que degrada com o crescimento da base, uma fila que acumula mensagens, uma migração de schema arriscada, um cache inconsistente, uma integração que perde eventos, um relatório que não bate com o sistema transacional. Depois de viver alguns desses cenários, a leitura deixa de ser apenas teórica e começa a organizar experiências que antes pareciam desconectadas.

Minha principal conclusão é que bons sistemas de dados nascem de boas perguntas. Qual consistência este fluxo realmente precisa? O que acontece se este nó falhar? Como este dado muda ao longo do tempo? Quem consome esta informação? Como vamos observar quando algo sair do esperado? Qual complexidade estamos aceitando em troca de desempenho, disponibilidade ou flexibilidade?

Essas perguntas não têm respostas universais, mas o livro dá repertório para respondê-las com mais cuidado. Para mim, esse é o maior mérito da leitura: sair dela menos interessado em escolher tecnologias por rótulo e mais preparado para discutir os trade-offs que sustentam uma decisão técnica.