Inglês
PortuguêsEsboço de arquitetura
Responda algumas perguntas sobre a sua aplicação e veja a arquitetura de partida: cada caixa diz por que está ali, quanto custa e quando seria exagero. E veja os dados andando por ela.
É um ponto de partida para a conversa, não uma revisão de projeto. Peças genéricas, sem fornecedor: o que importa é o papel de cada uma.
Comece por um exemplo
Sobre a aplicação
01Que tipo de aplicação?
02Quantas pessoas usam ao mesmo tempo, no pico?
Ao mesmo tempo, não por mês. Um site com 100 mil visitas por mês costuma ter menos de 100 pessoas ao mesmo tempo.
03Quanto tempo fora do ar ela aguenta?
04Ela mais lê ou mais grava dados?
05Precisa de atualização ao vivo?
06Faz trabalho pesado em segundo plano?
07Guarda arquivos enviados pelas pessoas?
08Precisa de busca por texto?
09Onde estão as pessoas?
10Quem constrói?
11Guarda dados pessoais sensíveis ou de pagamento?
Saúde, documentos, cartão. A LGPD e as regras de pagamento pedem cuidados extras.
A arquitetura
3 peçasEscolha uma situação e acompanhe o caminho, passo a passo.
Veja os dados andando
Legenda
O que você ainda não precisa
- Balanceador de cargaQuando chegar a mil pessoas ao mesmo tempo, ou quando ficar fora do ar deixar de ser aceitável.
- CacheQuando passar de 10 mil pessoas ao mesmo tempo, ou antes se a aplicação for quase só leitura.
- Réplicas de leituraCom muita leitura e mais de 10 mil pessoas ao mesmo tempo.
- Banco de prontidãoQuando a meta for 99,99%. Até lá, backup automático e restauração testada.
- CDNPara conteúdo público, loja, público em vários países ou muitos arquivos.
- FilaQuando aparecer trabalho que não precisa terminar antes da resposta.
- Motor de buscaQuando filtros não bastarem e a busca precisar de relevância.
- Gateway de tempo realQuando a conversa for nos dois sentidos (chat, colaboração).
- WAFCom dados sensíveis ou a partir de 100 mil pessoas ao mesmo tempo.
- Serviços por domínioQuando houver vários times precisando publicar sem esperar uns pelos outros.
- Segunda regiãoSó se ficar fora do ar com uma região inteira caída não for aceitável.
Levar para o seu projeto
Versão em texto
Componentes
- Usuários
- Aplicação (monólito modular) · Ponto único de falha
- Banco de dados · Ponto único de falha
- Logs e métricas
Conexões
- Usuários → Aplicação (Requisição e resposta)
- Aplicação → Banco de dados (Requisição e resposta)
Como funciona
As respostas passam por regras fixas, não por IA: as mesmas respostas sempre geram o mesmo diagrama, e cada caixa sabe dizer qual resposta a colocou ali.
Tudo começa no mínimo que qualquer aplicação precisa: uma aplicação, um banco de dados com backup automático, e logs e métricas. Cada resposta acrescenta só o que resolve um problema que ela cria: mais gente ao mesmo tempo pede várias cópias e um balanceador; muita leitura pede cache e réplicas; pouca tolerância a queda pede várias zonas e um banco de prontidão; arquivos pedem armazenamento próprio e CDN.
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.
Nada do que você responde sai do navegador. As respostas ficam no link, que você pode compartilhar.
Quer entender as regras por trás das caixas?
Leia o artigoFAQ
Quando vale a pena 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 entrega o mesmo isolamento de código com muito menos custo de rede, deploy e observabilidade.
Quando preciso de cache?
Quando o banco começa a responder muitas vezes a mesma pergunta: em geral, com milhares de pessoas ao mesmo tempo ou com uma aplicação quase só de leitura. Antes disso, o cache só traz o problema de dado desatualizado.
Qual a diferença entre 99,9% e 99,99% de disponibilidade?
99,9% permite cerca de 45 minutos fora do ar por mês; 99,99%, cerca de 4 minutos. Chegar ao segundo pede várias zonas, banco com failover automático e deploy sem parada, o que aumenta bastante custo e cuidado.
Para que serve uma fila numa aplicação web?
Para tirar trabalho lento da requisição: a aplicação guarda a tarefa, responde na hora, e workers fazem o trabalho em segundo plano, tentando de novo quando algo falha.
Esta ferramenta substitui um arquiteto?
Não. Ela dá um ponto de partida e um vocabulário comum para a conversa. Dados, orçamento, prazos e o time real mudam a resposta, e é aí que entra a revisão de alguém com contexto.