Quanta arquitetura a sua aplicação precisa? Do monólito às duas regiões em 11 perguntas

Toda conversa de arquitetura tem um momento em que o quadro já tem quinze caixas: fila, cache, réplicas, gateway, três microsserviços. Cada uma tem um bom motivo para existir em algum sistema. A pergunta que quase ninguém faz é se ela tem um bom motivo para existir neste sistema, agora.

Escrever essa pergunta em regras foi o ponto de partida do Esboço de arquitetura: você responde 11 perguntas sobre a aplicação e recebe um diagrama em que cada caixa diz por que está ali, quanto custa e quando seria exagero. Este texto explica as regras por trás dele.

O ponto de partida que quase sempre basta

Uma aplicação, um banco de dados relacional gerenciado com backup automático, e logs e métricas. Só isso.

Parece pouco, mas aguenta muito mais do que costumamos imaginar. Um banco bem indexado responde milhares de consultas por segundo, e uma aplicação bem escrita atende muita gente numa máquina só. O que esse desenho não tem é redundância: se a aplicação ou o banco caem, tudo cai. E isso pode ser aceitável. Um sistema interno, um projeto em validação ou um produto que aguenta algumas horas fora do ar por mês não precisam pagar por mais.

O que muda com cada resposta

Cada resposta acrescenta só o que resolve um problema que ela mesma cria:

• Mil pessoas ao mesmo tempo, ou pouca tolerância a queda: várias cópias da aplicação atrás de um balanceador de carga. Uma máquina só tem um teto e é um ponto único de falha.
• Dez mil pessoas ao mesmo tempo, ou uma aplicação que quase só lê: um cache em memória na frente do banco, para não perguntar a mesma coisa mil vezes.
• Muita leitura com dez mil pessoas: réplicas de leitura. As escritas continuam indo ao banco principal.
• 99,99% de disponibilidade: cópias em mais de uma zona e um banco de prontidão, que assume sozinho se o principal cair.
• Nem uma região inteira pode derrubar o serviço: uma segunda região. É a resposta mais cara da ferramenta, e ela avisa isso.
• Arquivos enviados pelas pessoas: armazenamento de objetos e uma CDN. Arquivo não mora no banco nem no disco da aplicação.
• Trabalho pesado em segundo plano: uma fila e workers. A requisição responde na hora, e o trabalho lento acontece depois, com novas tentativas quando algo falha.
• Conversa nos dois sentidos (chat, colaboração): um gateway de tempo real e um pub/sub entre as cópias. Se o servidor só avisa, eventos do servidor saindo da própria aplicação bastam.

Os números (mil, dez mil) são regras práticas, não leis. Eles servem para mostrar a ordem de grandeza em que cada peça começa a se pagar.

Para comparar com o ponto de partida: com as respostas de uma loja na Black Friday (até 100 mil pessoas ao mesmo tempo, 99,99% de disponibilidade, busca completa, dados de pagamento e vários times), o mesmo questionário chega a 16 peças.

"Ao mesmo tempo" é o número que importa

O número que mais engana é o de usuários. Um site com 100 mil visitas por mês parece grande, mas as visitas se espalham pelo mês, pelo dia e pelas horas. Quem dimensiona a infraestrutura é o pico de pessoas usando ao mesmo tempo, e ele costuma ser muito menor do que o total do mês. Por isso a ferramenta pergunta exatamente isso, com uma dica embaixo.

Ponto único de falha nem sempre é um problema

O diagrama marca com um alerta as peças cuja queda derruba tudo. Num produto pequeno, a aplicação e o banco aparecem marcados, e a explicação diz que isso pode ser aceitável. Disponibilidade custa caro, e cada nove a mais custa mais que o anterior: é a mesma ideia que o livro de SRE do Google chama de aceitar o risco certo, em vez de buscar 100%. A pergunta certa é quanto tempo fora do ar o negócio aguenta, e a ferramenta começa por ela.

Microsserviços são uma decisão de time

A regra mais importante não tem a ver com escala: com um time, a ferramenta recomenda um monólito modular, um só deploy com módulos bem separados. Serviços por domínio só entram quando há vários times que precisam publicar sem esperar uns pelos outros. Mesmo assim, ela avisa o custo: rede, deploys, observabilidade e dados espalhados. Martin Fowler descreve o mesmo padrão em MonolithFirst: as histórias de microsserviços que deram certo quase sempre começaram com um monólito que cresceu demais e foi dividido.

O que você ainda não precisa

Abaixo do diagrama há uma lista com o que ficou de fora e o que faria cada peça entrar. Para um produto com cem pessoas ao mesmo tempo: sem cache, sem réplicas, sem microsserviços, e a resposta que mudaria cada decisão. É a parte que mais ajuda numa conversa com o time: tira o "e se a gente crescer?" do campo da ansiedade e coloca num gatilho concreto.

Como a ferramenta foi feita

• Regras fixas, não IA. As mesmas respostas sempre geram o mesmo diagrama, e cada regra tem um teste automático.
• Cada peça com a sua cor e o seu formato. A cor diz a categoria (entrada e rede, processamento, mensageria, dados, apoio), e o formato diz o tipo: banco de dados é cilindro, fila guarda as mensagens enfileiradas, o tópico de pub/sub é um tubo, o cache é um chip de memória, o armazenamento de arquivos é um balde. Dá para reconhecer a peça antes de ler o nome.
• Dados em movimento. O diagrama usa React Flow. As setas mostram o sentido dos dados, e cenários como "abrir uma página" ou "enviar um arquivo" percorrem o caminho um salto por vez: só a peça que recebe os dados brilha, na cor dela, com uma legenda para cada passo e narração opcional.
• Para levar ao projeto. Dá para baixar o diagrama em PNG, copiar o código Mermaid (que vira diagrama no GitHub e no Notion) e baixar um ADR, o registro de decisão de arquitetura que Michael Nygard popularizou, já com contexto, decisão, prós e contras e quando revisar.
• Nada sai do navegador. As respostas ficam no endereço da página: dá para recarregar, guardar ou compartilhar o link.

As peças são genéricas de propósito: balanceador, cache, fila e réplica são os mesmos conceitos há mais de dez anos, em qualquer nuvem ou servidor próprio. Escolher o produto é o passo seguinte, e depende de coisas que um questionário não sabe: o time, o orçamento, o que vocês já operam bem.

Experimente com o seu próximo projeto: abrir o Esboço de arquitetura.

Lições

1. Comece com uma aplicação, um banco com backup e logs. Cada peça a mais precisa de um motivo concreto.
2. Dimensione pelo pico de pessoas ao mesmo tempo, não pelas visitas do mês.
3. Defina quanto tempo fora do ar o negócio aguenta antes de desenhar redundância.
4. Microsserviços seguem o número de times; com um time, um monólito modular entrega o mesmo isolamento por menos.
5. Registre também o que ficou de fora e quando rever: isso transforma "e se crescer?" num gatilho claro.

Perguntas frequentes

Qual é a arquitetura mínima para uma aplicação web?

Uma aplicação, um banco de dados gerenciado com backup automático, e logs e métricas. Ela aguenta muito tráfego; o que falta é redundância, que só vale o custo quando ficar fora do ar deixa de ser aceitável.

Quando devo usar microsserviços?

Quando vários times precisam publicar partes do produto sem esperar uns pelos outros. Com um time só, um monólito modular dá o mesmo isolamento de código com menos custo.

Quando colocar cache na aplicação?

Quando o banco passa a responder muitas vezes a mesma pergunta: em geral com milhares de pessoas ao mesmo tempo, ou numa aplicação que quase só lê. Antes disso, o cache só traz o problema de dado desatualizado.

Como gerar um diagrama de arquitetura a partir de requisitos?

O Esboço de arquitetura, em rafaelfachinelli.com/pt-BR/tools/architecture, faz isso com 11 perguntas e exporta o resultado em PNG, Mermaid e rascunho de ADR. É gratuito e roda no navegador.

Referências

• MonolithFirst, Martin Fowler
• Embracing Risk, Site Reliability Engineering (Google)
• Documenting Architecture Decisions, Michael Nygard
• React Flow