Em Defesa de Arquiteturas Simples (2022)

Artigo original ↗ Discussão no Hacker News ↗

Engenheiros avaliam os benefícios de arquiteturas “sem graça”, monolíticas, contra stacks complexos e pesados em microsserviços, argumentando que a maioria dos negócios pode escalar muito bem com um único app bem estruturado apoiado por um banco relacional. Muitos culpam o desenvolvimento movido por currículo, o hype em torno de padrões no estilo FAANG e uma liderança técnica fraca pela complexidade desnecessária que prejudica a confiabilidade, desacelera a entrega e esgota as equipes. Outros observam que microsserviços e designs orientados a eventos podem ser justificados para escala organizacional ou necessidades específicas de desempenho, mas apenas quando guiados por restrições reais e não por moda.

Arquiteturas simples vs. complexas

  • Muitos comentaristas defendem stacks “sem graça” (Rails/Django ou Python+Postgres, templates SSR + htmx, um único VPS) como suficientes para a maioria dos apps CRUD/de negócios, especialmente B2B.
  • Eles enfatizam que sistemas simples são mais fáceis de entender, manter, depurar e contratar para dar suporte; “velho e confiável” muitas vezes supera “novo e brilhante”.
  • Outros argumentam que o que conta como “simples” é subjetivo: containers, k8s, GraphQL ou I/O assíncrono podem parecer simples para quem os conhece e complexos para outras pessoas.

Monólitos, microsserviços e event sourcing

  • Há forte apoio para começar com um monólito, estruturado com módulos e fronteiras claras; muitos afirmam que um monólito disciplinado pode escalar muito.
  • Críticos dos microsserviços dizem que eles não reduzem a complexidade, apenas a transferem pela rede, tornando consistência, transações, depuração e deploys mais difíceis.
  • Vozes pró-microsserviços os apresentam principalmente como uma ferramenta organizacional e de coordenação: permitindo equipes independentes, falhas isoladas e escalonamento direcionado.
  • Event sourcing/CQRS é proposto por alguns como “microsserviços feitos do jeito certo”, mas outros o chamam de imaturo e complexo (exclusão de PII, semântica de replay, determinismo).

Escolhas tecnológicas: Python, GraphQL, Kubernetes

  • Alguns acham que a stack descrita (monólito em Python + Postgres + filas + GraphQL + k8s + protocolo customizado) não é realmente “simples” e questionam várias dessas escolhas.
  • Há debates sobre Python em finanças: tipagem estática é vista por alguns como vital para lidar com dinheiro; outros argumentam que o ecossistema moderno de Python (mypy, C FFI, bibliotecas ricas) é suficiente.
  • GraphQL recebe elogios (reduz a proliferação de endpoints REST, schema compartilhado, tipagem forte) e também críticas (complexidade conceitual, tamanho das respostas, não ser estritamente necessário em vez de REST).
  • Kubernetes é visto por alguns como overhead desnecessário para equipes pequenas; outros dizem que um cluster k8s gerenciado pode ser uma forma direta de operar um app “comum” de três camadas.

Fatores humanos e organizacionais

  • Muitos culpam a complexidade por uma engenharia movida por currículo ou “pegadora de itens brilhantes”: adotar Kafka/microsserviços/cloud/etc. para aprender ou impressionar, não para resolver problemas reais.
  • Outros observam que a exploração tem valor, mas deve acontecer em protótipos, projetos paralelos ou contextos restritos, não em sistemas centrais de produção.
  • Vários enfatizam que a arquitetura deve corresponder à realidade da organização: tamanho da equipe, experiência, ownership e incentivos importam mais do que padrões específicos.

Escala, desempenho e “você não vai precisar disso”

  • Um grupo argumenta que I/O síncrono e bancos de dados únicos lidam facilmente com “milhões de requisições por mês”; escale com máquinas maiores antes da complexidade distribuída.
  • Outro grupo alerta que I/O bloqueante e stacks mal escolhidas podem cair mesmo com baixo volume, especialmente quando a latência de sistemas downstream aumenta.
  • Há um amplo consenso de que construir cedo demais “como a Netflix” derrubou ou desacelerou muitas empresas, mas também de que projetar de menos pode sair caro para corrigir depois.

Carreiras, incentivos e valor

  • Alguns temem que focar em “tecnologia sem graça” prejudique as perspectivas de carreira porque a contratação muitas vezes filtra por stacks da moda.
  • Outros respondem que impacto comercial quantificável (“economizou X, permitiu receita Y”) é mais convincente em níveis seniores do que bingo de tecnologias.
  • Vários apontam incentivos desalinhados: capital barato e crescimento a qualquer custo incentivaram complexidade desperdiçadora; aproximar engenheiros dos resultados de negócio é sugerido como correção.