monolitos são sistemas implementados como uma única unidade coesa, onde todos os componentes residem juntos. utiliza um único código-fonte, e gera um único artefato de deploy.

imutabilidade do artefato

cada mudança, por menor que seja, demanda a atualização e recompilação do sistema como um todo.

monolito clássico

é a forma mais tradicional da arquitetura monolítica. sua principal característica é que toda a aplicação roda dentro de um único processo.

  • escalabilidade: é possível escalar executando múltiplas instâncias desse processo (escala horizontal), mas a lógica permanece centralizada.
  • acoplamento: toda a lógica é centralizada e fortemente acoplada.
  • camadas lógicas: é possível (e recomendável) dividir o código em camadas lógicas, mas não existem barreiras técnicas que limitem as integrações entre os pedaços do projeto.

risco de "código espaguete"

o crescimento da aplicação sem barreiras rígidas tende a levar a um forte acoplamento, dificultando a manutenção.

lei de conway

"qualquer organização que desenhe um sistema produzirá um design cuja estrutura é uma cópia da estrutura de comunicação da organização." — lei de conway

  • silos funcionais: como as equipes são frequentemente organizadas por função (backend, frontend, DBA) e não por produto ou negócio, o software resultante tende a ser um bloco único separado apenas por camadas técnicas, e não por domínios de negócio.
  • barreiras de comunicação: a dificuldade de comunicação entre estes silos reforça o acoplamento dentro do código, pois não há incentivo organizacional para criar interfaces (APIs) limpas entre domínios.

características técnicas e operacionais

infraestrutura e código

  • a aplicação toda corre como um único processo no servidor.
  • código centralizado; geralmente todo o desenvolvimento ocorre num repositório principal.
  • desenvolvimento com uma única linguagem (na grande maioria dos casos)
  • implantação de artefato único.
  • gestão, configuração, monitoramento e deploy são centralizados na mesma aplicação.

dados e comunicação

  • base de dados compartilhada por todos os módulos da aplicação.
  • chamadas diretas de métodos (in-memory), sem dependência de APIs internas ou latência de rede entre módulos.

monolithic hell

é o ponto onde a complexidade do sistema ultrapassa a capacidade cognitiva da equipe.

  • ciclos de desenvolvimento lentos e dolorosos
  • medo de realizar deploys (quebra frequente)
  • impossibilidade de escalar apenas as partes críticas
  • bloqueio tecnológico (lock-in de framework/linguagem)
  • dificuldade no onboarding e curva de aprendizado íngreme
  • dificuldade em identificar impactos e riscos de mudanças

vantagens

simplicidade

  • as IDEs lidam melhor com uma única base de código.
  • é mais fácil entender o fluxo completo de uma funcionalidade quando o código está todo no mesmo lugar.
  • implantação simplificada de artefato único.
  • não exige, inicialmente, ferramentas pesadas de orquestração (como kubernetes complexos) para gerir a comunicação entre dezenas de serviços

performance e comunicação

  • zero latência de rede, pois a comunicação entre componentes ocorre em memória
  • evita o overhead de serialização/deserialização e o handshake de protocolos de rede (HTTP/gRPC) que ocorre em sistemas distribuídos.

regra de ouro

em sistemas onde a performance em tempo real é crítica, a latência introduzida por chamadas remotas distribuídas pode ser proibitiva.

consistência de dados

  • facilidade em garantir transações ACID (atomicidade, consistência, isolamento, durabilidade), já que existe normalmente uma única base de dados.
  • se uma parte da operação falha, a base de dados reverte tudo automaticamente, sem a necessidade de implementação de padrões de rollback complexos .
  • é consideravelmente mais fácil escrever e executar testes de integração e end-to-end (E2E) quando a aplicação é uma unidade só. não há necessidade de mockar serviços externos de rede ou garantir que diversos microserviços estejam de pé na versão correta para rodar um teste.

segurança

  • a autenticação e autorização são configuradas num único ponto de entrada.

monitoramento

  • menos métricas dispersas para correlacionar.