Guias / system-design
System design
Como projetar sistemas grandes e escaláveis, e como conduzir uma entrevista de system design: requisitos, estimativas, blocos de construção e trocas.
31 jan 2025· 4 min· 7 seções
Neste guia · 7 seções
O que se avalia
Como desenvolver sistemas grandes e escaláveis? Numa entrevista de system design não existe resposta certa: o que se avalia é o quanto você sabe de arquitetura, sua maturidade e seu repertório. Por isso vale ter alguns casos reais na manga e, principalmente, perguntar muito sobre os requisitos antes de desenhar.
O roteiro
Uma entrevista típica tem de 40 a 50 minutos. Controle o tempo e mantenha anotações do que deve ser discutido.
- Escopo e requisitos: motivo, público, funcionalidades principais e requisitos não funcionais (latência, disponibilidade, volume).
- Solução de alto nível:
- De cima para baixo, focando nas funcionalidades definidas.
- Defina como as partes se comunicam (REST, gRPC, WebSockets).
- Desenhe o schema conforme a solução escolhida.
- Não entre em detalhes antes de o desenho geral estar de pé.
- Aprofundar: para cada problema, traga duas soluções, discuta as trocas e escolha uma.
- Fechamento: resuma, aponte gargalos e o que faria com mais tempo.
Estimativas de capacidade
Antes de escolher tecnologia, estime: acessos por dia e por hora, picos, banda, disco para 1 a 5 anos e redundância. Contas de guardanapo bastam.
Exemplo: um encurtador de links com 100 milhões de novos links por mês.
| Conta | Resultado |
|---|---|
| Escritas por segundo | 100 mi ÷ (30 × 24 × 3.600) ≈ 40/s |
| Leituras (proporção 100:1) | ≈ 4.000/s |
| Disco em 5 anos (500 bytes por link) | 100 mi × 12 × 5 × 500 B ≈ 3 TB |
Conclusão: é um sistema de leitura pesada, então cache e réplicas de leitura importam mais que o banco de escrita.
Blocos de construção
Bancos de dados
| Tipo | Bom para | Exemplos |
|---|---|---|
| Relacional | Dados estruturados, transações, consultas flexíveis | PostgreSQL, MySQL |
| Documento | Estruturas que variam, leitura do objeto inteiro | MongoDB |
| Chave-valor | Acesso muito rápido por chave, cache, sessão | Redis, DynamoDB |
| Colunar | Grandes volumes de escrita, séries temporais | Cassandra |
| Grafo | Relações complexas (redes sociais, recomendação) | Neo4j |
| Busca | Texto livre, filtros e relevância | Elasticsearch |
Bancos relacionais oferecem transações ACID: atomicidade (tudo ou nada, com commit e rollback), consistência, isolamento (transações simultâneas não se atrapalham) e durabilidade (o que foi confirmado sobrevive a quedas). Muitos bancos NoSQL abrem mão de parte disso em troca de escala, aceitando consistência eventual.
Comunicação e entrada
- APIs: REST (simples e universal), gRPC (eficiente entre serviços), GraphQL (o cliente escolhe os campos).
- Load balancer (Nginx, Traefik): distribui tráfego e pode separar leituras de escritas.
- Cache: na frente do banco para leituras repetidas.
- WebSockets: para tempo real; escalar exige cuidar de conexões longas e de qual instância tem cada usuário.
Mensageria
Desacopla quem produz de quem consome e absorve picos. Filas (SQS, RabbitMQ) para trabalho distribuído; tópicos e streaming (Kafka, Pub/Sub) para eventos com vários consumidores; processamento de streams com Flink.
Observabilidade e dados
Observabilidade desde o começo, e um data lake quando o negócio precisa analisar o histórico.
Bancos de dados × microsserviços
| Um banco por serviço | Um banco compartilhado | |
|---|---|---|
| Acoplamento | Baixo: cada serviço evolui sozinho | Alto: mudar uma tabela afeta vários serviços |
| Escala | Independente | Um serviço pesado afeta todos |
| Dados | Levemente duplicados, consistência eventual, risco de dessincronia | Consistentes, mas sem dono claro |
A regra geral é um banco por serviço, com eventos para sincronizar o que for preciso (veja CQRS).
Dicas
- Pesquise tecnologias que resolvam o problema, mas não proponha o que você não domina.
- Equilibre padrões de projeto, código limpo e alta performance: nem sempre os três cabem juntos.
- Fale as trocas em voz alta: o entrevistador quer ver o raciocínio.
Referências
- System Design Primer: material aberto com os blocos de construção e exercícios.
- Designing Data-Intensive Applications (Martin Kleppmann, O’Reilly): a referência para bancos, replicação e consistência.