System design é o processo de definir a estrutura, os componentes e as interações de um software para que ele cumpra suas funções e mantenha qualidades como confiabilidade, segurança, desempenho, custo e facilidade de operação. Para começar, defina o que o sistema precisa fazer e sob quais limites, desenhe o fluxo principal e só depois compare opções de arquitetura.
O que é system design
Em system design, a pergunta central não é “qual tecnologia usar?”, e sim “qual estrutura atende a este problema, com estes usuários, este volume e estas restrições?”. A resposta costuma envolver quatro coisas: os componentes que existem (aplicação, API, banco de dados, fila, cache), a responsabilidade de cada um, a forma como eles se comunicam e o que acontece quando alguma parte falha.
As an Amazon Associate I earn from qualifying purchases.
Esse trabalho acontece antes e durante a programação. Uma boa especificação de arquitetura explica não só o que foi escolhido, mas também por que foi escolhido, quais requisitos funcionais e não funcionais motivaram a decisão, quais restrições existiam e quais alternativas foram descartadas. Essa última parte é a que mais ensina, porque mostra o raciocínio, não apenas o resultado.
Antes de desenhar: requisitos e limites
Requisitos funcionais descrevem o que o sistema faz: cadastrar pedidos, enviar notificações, calcular frete. Requisitos não funcionais descrevem com que qualidade ele faz isso: quanto tempo uma resposta pode demorar, quanto tempo o sistema pode ficar indisponível por mês, quais dados precisam de proteção especial, quanto custa operar, quão rápido a operação consegue recuperar um serviço após uma falha.
#1 Best Overall
Esses requisitos mudam a solução de forma concreta. Um sistema de reservas de ingressos e um relatório interno que roda uma vez por noite podem usar a mesma linguagem e até o mesmo banco de dados, mas exigem arquiteturas muito diferentes, porque um tolera atraso de segundos e o outro quase não tolera indisponibilidade no pico de venda.
Ao estimar carga, use números como hipóteses declaradas, não como fatos. Por exemplo: “supondo 200 pedidos por minuto no pico e 10 leituras para cada escrita, o banco recebe cerca de 2.000 leituras por minuto”. Depois pergunte como a solução mudaria se essa hipótese dobrasse ou caísse pela metade. Esse exercício mostra quais decisões são sensíveis ao volume e quais não são.
Por onde começar: roteiro prático
- Defina o problema e os usuários. Escreva em poucas frases quem usa o sistema, quais são as funções centrais e qual resultado precisa existir ao final de cada uma. Se não for possível escrever essas frases, a arquitetura ainda não tem base para ser escolhida.
- Torne os requisitos não funcionais explícitos. Para cada um, pergunte: latência, disponibilidade, segurança, custo e capacidade de recuperação importam quanto, neste caso? Frameworks oficiais de arquitetura organizam essas decisões em torno de atributos de qualidade e de objetivos da carga de trabalho (workload).
- Desenhe apenas o caminho principal. Mostre o cliente, a API ou serviço, o armazenamento e as dependências que de fato participam da tarefa mais importante. Um diagrama com cinco caixas e setas nomeadas é mais útil do que um com vinte caixas que ninguém consegue ler. Documentar componentes, interações e fluxo de dados também ajuda a localizar riscos e gargalos.
- Estime a carga com hipóteses declaradas. Identifique volume, proporção de leituras e escritas, crescimento esperado e picos, e registre cada número como suposição. A pergunta que importa é como a solução mudaria se a suposição estivesse errada.
- Procure falhas e gargalos no desenho. Para cada seta do diagrama, considere o que acontece se a rede atrasar, se o serviço do outro lado estiver indisponível ou se a operação precisar ser repetida. Google Cloud recomenda, em seu framework de arquitetura, delimitar o escopo, entender como os componentes interagem e identificar o que pode dar errado.
- Compare poucas opções e seus custos. Por exemplo, uma chamada síncrona é direta quando o usuário espera a resposta na mesma tela, como ao confirmar um pagamento. Processamento assíncrono ou em lote pode servir quando o trabalho pode esperar, como enviar um e-mail de confirmação ou gerar um relatório. A AWS distingue esses padrões e orienta a escolha conforme o tipo de sistema e as exigências de resposta.
- Adicione complexidade somente com justificativa. Só inclua um elemento novo quando houver um problema específico que ele resolve, como descrito na seção a seguir.
Quando adicionar complexidade
Filas, réplicas, caches, particionamento e múltiplos serviços resolvem problemas reais, mas cada um também cria operação extra e novos modos de falha. Antes de incluir um desses elementos, escreva o problema que ele resolve e o custo que ele traz.
- Fila: resolve trabalho que pode ser feito depois e desacopla etapas. Traz atraso variável, possibilidade de processar a mesma mensagem duas vezes e a necessidade de monitorar mensagens paradas.
- Cache: reduz trabalho repetido em leituras frequentes. Traz o risco de dados desatualizados e a regra de quando invalidá-los.
- Réplicas de leitura: distribuem consultas quando o banco principal está sobrecarregado por leituras. Traz atraso entre a escrita e a leitura nas réplicas, que o usuário pode perceber.
- Particionamento: divide dados ou carga entre partes quando um único nó não comporta o volume. Traz consultas que cruzam partições e mais trabalho de reequilíbrio.
- Múltiplos serviços: separam times e ciclos de implantação. Trazem chamadas de rede entre serviços, versionamento de contratos e mais pontos a observar.
Como comparar arquiteturas
Ao comparar duas ou mais alternativas, use sempre os mesmos eixos. Isso evita escolher pela opção mais familiar ou mais moderna.
| Eixo | Pergunta de comparação |
|---|---|
| Funcionalidade | A solução cobre os fluxos essenciais e mantém os dados corretos? |
| Desempenho e escala | Como muda a resposta quando volume ou concorrência crescem? |
| Confiabilidade e recuperação | O que ocorre quando uma dependência ou zona falha? Como o sistema se recupera? |
| Segurança | Como proteger dados e workloads e atender às exigências aplicáveis? |
| Operação | Como será implantado, observado, mantido e corrigido? |
| Custo e sustentabilidade | Que recursos são necessários e que custo operacional ou ambiental decorre das escolhas? |
Os grandes provedores de nuvem publicam frameworks com pilares diferentes. A AWS Well-Architected Framework lista seis pilares: excelência operacional, segurança, confiabilidade, eficiência de desempenho, otimização de custos e sustentabilidade. O Google Cloud Architecture Framework também usa seis pilares, com otimização de desempenho entre eles e perspectivas transversais. O Azure Well-Architected Framework usa cinco pilares. A diferença de nomes não muda o método: use os requisitos do seu sistema como critério, em vez de decorar uma lista. Esses frameworks são guias de provedores e descrevem boas práticas de arquitetura; eles não comprovam que uma solução específica seja superior em todos os casos.
Falhas em sistemas distribuídos
Assim que um sistema depende de uma rede, ele precisa funcionar apesar de perda de mensagens e de atrasos. A AWS explica que sistemas distribuídos devem operar mesmo quando dados se perdem ou chegam atrasados, e recomenda duas práticas básicas para limitar a propagação de falhas: manter as dependências pouco acopladas e tornar as operações mutáveis idempotentes, isto é, repetir uma solicitação não deve repetir indevidamente seus efeitos.
Rank #3
Um exemplo simples: se o cliente de um pagamento expira sem receber resposta e tenta de novo, o sistema não deve cobrar duas vezes. Uma forma comum de garantir isso é enviar um identificador único com cada solicitação e registrar se ela já foi processada.
A confiabilidade, nesse sentido, combina quatro práticas: observar o sistema para detectar problemas cedo, planejar a recuperação antes do incidente, usar redundância quando ela se justifica e projetar degradação controlada. Por exemplo, se o serviço de recomendações cair, uma loja pode continuar exibindo o catálogo e ocultar apenas o bloco de sugestões.
A Microsoft resume a questão assim: “The Azure Well-Architected Framework can set you up for success through architectural design, but the implementation choices depend on the business requirements and constraints of your organization.” (Microsoft Learn, “What is the Azure Well-Architected Framework?”). Em tradução livre: o framework ajuda no desenho, mas as escolhes de implementação dependem dos requisitos e restrições do negócio.
Rank #4
Conceitos que valem estudar primeiro
- Contratos de API: o que cada serviço promete, quais dados aceita e devolve e como muda sem quebrar quem o consome. A documentação de arquitetura da Microsoft recomenda explicitar contratos de API e de dados e a estratégia de compatibilidade.
- Modelagem de dados: como os dados são organizados, consultados, atualizados e protegidos. Muitas decisões de arquitetura começam aqui.
- Escala vertical e horizontal: aumentar os recursos de uma instância ou distribuir o trabalho entre instâncias. A escolha depende da carga, dos limites do sistema e do custo. O Google Cloud aponta a escalabilidade horizontal como princípio de confiabilidade.
- Cache, filas e processamento assíncrono: ferramentas para reduzir trabalho repetido ou desacoplar etapas. Exigem decidir sobre consistência, atraso, duplicação e recuperação.
- Tolerância a falhas e observabilidade: detectar problemas, conter o impacto, restaurar o serviço e aprender com incidentes.
- Segurança e custo: são requisitos de arquitetura desde o início, não acabamento feito no fim do projeto.
Para aprofundar: um livro, depois dos fundamentos
Designing Data-Intensive Applications, 2ª edição, de Martin Kleppmann e Chris Riccomini, publicado pela O’Reilly Media em 2026, trata de aplicações intensivas em dados, incluindo sistemas distribuídos, falhas e processamento. É uma leitura mais profunda, indicada depois de você ter fundamentos de programação e já ter desenhado alguns sistemas simples. Não é pré-requisito para começar. Confirme a edição e a disponibilidade no site da editora antes de comprar.
Sobre números e estatísticas
Este guia não usa estatísticas de mercado. As documentações oficiais de arquitetura citadas tratam de princípios, pilares e recomendações, e não de cifras aplicáveis a todos os projetos. Quando você estimar volume, trate os números como hipóteses do seu caso, não como dados de referência.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
