Dando sequência à trilha iniciada na primeira parte, a conversa retoma o roadmap de back-end a partir de design de software e princípios de desenvolvimento, avançando por padrões arquiteturais, mensageria, containerização, GraphQL, bancos de dados para grafos, comunicação em tempo real e escalabilidade. O fio condutor é sempre o mesmo: nenhuma tecnologia é bala de prata, e a decisão de adotar algo complexo precisa vir de uma necessidade real, não de modismo.
Jessica Nathany e João Souza já haviam participado da primeira parte do roadmap de back-end e retornam para esta continuação. Jessica atua com desenvolvimento voltado a soluções de e-commerce e trouxe experiência prática com Elasticsearch aplicado à busca de produtos, além de vivência com RabbitMQ em sistemas de notificação para produtos financeiros. João atua em uma plataforma com mais de 200 serviços em produção, lidando diretamente com arquitetura orientada a eventos, Kafka, partições e escalabilidade de microsserviços em cenários de altíssimo volume transacional. Os dois trazem, ao longo da conversa, exemplos concretos do dia a dia corporativo para ilustrar cada tópico do roadmap.
A discussão sobre KISS e YAGNI mostra que simplicidade não significa evitar complexidade a qualquer custo, mas sim reconhecer quando ela é realmente necessária. O exemplo de granularizar demais um sistema em microsserviços — criando camadas extras, custos adicionais e dificuldade de rastrear erros — ilustra como a adoção de padrões "da moda" sem necessidade real gera mais problemas do que resolve.
"Tudo é equilíbrio, tudo tem seus pros e seus contras, o monolito tem as suas dificuldades, agora a gente está passando pelas do microsserviço, a gente quis tornar muito complexo por abordar puramente o conceito de microsserviços" por João Souza
Kafka aparece como solução robusta para cenários de altíssimo volume e processamento distribuído, com recursos como partições e replay de mensagens, mas exige maturidade técnica e não é indicado para todo cenário — houve até um caso de rollback depois de uma tentativa de substituir HTTP por Kafka que piorou a performance em um sistema de tempo real. RabbitMQ, por outro lado, é descrito como mais simples de configurar e mais acessível para quem está começando com arquitetura orientada a eventos.
"A gente já teve várias surpresas com a aplicação lá também, como, por exemplo, perda de performance em alguns cenários, onde a gente aplicou, trocou a comunicação HTTP por Kafka, que a gente perdeu e teve que fazer o rollback da solução" por João Souza
Containerização é tratada como conhecimento obrigatório para qualquer desenvolvedor atual, independentemente de atuar com infraestrutura ou não. O ganho não é apenas técnico — reduzir custo de servidor, padronizar ambientes de desenvolvimento e produção e permitir deploys sem downtime aparecem como benefícios recorrentes na experiência de quem já viveu a era anterior, de configuração manual de servidores físicos.
"Cara, eu acho que Docker num roadmap é obrigatório, é algo que eu acho que hoje em dia vai perdurar por muito tempo" por João Souza
A crítica ao uso indiscriminado de GraphQL é um dos pontos mais diretos da conversa. A visão defendida é que REST bem implementado resolve a grande maioria dos cenários, e que GraphQL só se justifica quando há múltiplos front-ends consumindo dados muito diferentes de uma mesma API, tornando o versionamento de endpoints inviável.
"Eu acho que assim, quando você está usando REST, quando você está usando bem REST, você pode criar soluções que contornam essa parada... eu acho que é outra coisa que eu só utilizaria se eu tivesse assim, cara, 100% necessário" por João Souza
O contraste entre escala vertical (servidores físicos, limitada) e escala horizontal (containers, auto-scale) é ilustrado com casos reais de sobrecarga em sistemas de governo e picos de Black Friday em soluções antifraude. Mas o alerta mais importante é que escalar automaticamente sem observabilidade pode mascarar um problema real — como um serviço que morre e sobe repetidamente em loop, consumindo recursos sem que ninguém perceba a causa raiz.
"Não é porque ele cresce, que, ah, não, tudo bem, mas por que cresceu? Será que foi um erro que está acontecendo? Às vezes acontece isso, um serviço está morrendo e aí está levantando outras instâncias para poder suprir a morte dos outros" por Jessica Nathany
"O que define o aprendizado é a constância, não a intensidade" por João Souza