Decisão de arquitetura é diferente de decisão de código por um motivo cruel: ela cobra juros. Um if mal escrito se corrige em minutos. Uma fronteira de sistema mal desenhada acompanha o produto por anos, encarecendo cada sprint seguinte.

Neal Ford e Mark Richards, autores de Fundamentals of Software Architecture (O'Reilly), definem arquitetura como o conjunto de decisões difíceis de mudar depois. É exatamente por isso que algumas merecem mais atenção do que recebem. Estas são as cinco de que mais vemos times se arrependerem.

1. Escolher a stack pela moda, não pelo problema

O framework do momento tem palestra bonita, benchmark impressionante e zero compromisso com o seu contexto. A pergunta certa nunca é "o que está em alta?", e sim: meu time domina isso? A comunidade é madura? Contrata-se gente para essa stack no meu mercado?

Tecnologia nova em produto crítico significa aprender os problemas dela em produção, com cliente dentro. O custo não aparece no primeiro mês; aparece no décimo, quando o único dev que dominava a ferramenta sai da empresa.

2. Microsserviços no dia zero

Já dedicamos um artigo inteiro a essa decisão, então aqui vai só o resumo: distribuir um sistema antes de entender seu domínio é assinar um contrato de complexidade (rede, consistência eventual, dezenas de pipelines) sem ter os benefícios que a justificam. Comece modular. Extraia serviços quando a dor for real e medida.

3. Integrar sistemas pelo banco de dados

É a decisão que parece atalho e vira algema: dois sistemas lendo e escrevendo na mesma tabela. Funciona na demo. Meses depois, ninguém consegue alterar um schema sem quebrar o vizinho, e todo deploy exige reunião entre times.

Integração saudável passa por contratos explícitos: APIs, eventos, filas. O banco é detalhe interno de cada serviço, não o barramento da empresa. Quando o schema vira interface pública, você perdeu o direito de evoluí-lo.

4. Crescer sem fronteiras de domínio

O sistema começa pequeno, todo mundo mexe em tudo, e "depois a gente organiza". Foote e Yoder deram nome a esse destino no paper mais honesto da literatura de arquitetura: Big Ball of Mud (1997), a grande bola de lama em que tudo depende de tudo (o paper original).

O antídoto não é burocracia: é fronteira explícita. Módulos com responsabilidade clara, dependências numa direção só, domínio de negócio refletido na estrutura do código. É o que permite que o monolito de hoje vire, se preciso, os serviços de amanhã, sem reescrita.

5. Deixar observabilidade e automação "para depois"

Logs estruturados, métricas, deploy automatizado e rollback fácil parecem luxo enquanto tudo funciona. No primeiro incidente sério, viram a diferença entre 15 minutos e uma madrugada inteira de guerra, na base do SSH e do achismo.

O detalhe que poucos contam: instrumentar depois custa muito mais caro do que nascer instrumentado. Adicionar logs e métricas num sistema em produção é cirurgia; incluir desde o primeiro deploy é hábito.

O padrão por trás dos cinco arrependimentos

Repare que nenhum desses erros é técnico no sentido estrito. Todos nascem do mesmo lugar: decidir sem registrar o contexto e sem medir o trade-off. A arquitetura certa para uma startup de 5 pessoas é errada para uma operação de 15 times, e vice-versa.

Por isso, times maduros documentam decisões em ADRs (Architecture Decision Records), formato proposto por Michael Nygard: uma página por decisão, com contexto, alternativas e consequências (Documenting Architecture Decisions). Quando o contexto mudar, você sabe o que revisitar e por quê.

Antes de assinar a próxima decisão

Se o seu produto está nascendo agora, ou se alguma dessas cinco já está cobrando juros aí dentro, vale uma segunda opinião antes do próximo grande passo. No nosso serviço de Arquitetura de Software, revisamos o desenho atual, mapeamos riscos e entregamos um plano de evolução com trade-offs explícitos, sem reescrever o que não precisa.

Quer saber qual dessas cinco é a mais urgente no seu sistema? Descreva seu cenário para a IA da Rabelo Digital, aqui no canto da tela. Sem formulário, sem espera.

---

Leia também

• Event-Driven Architecture explicada
• Clean Architecture na prática
• Monolito vs Microsserviços: quando usar cada um