Entrevistas de System Design sao a parte mais temida do processo seletivo para vagas senior e em big techs. Diferente de coding interviews (que testam resolucao de problemas), system design testa sua capacidade de projetar sistemas completos, considerar tradeoffs e comunicar decisoes arquiteturais. Este guia mostra como se preparar e abordar qualquer pergunta.
O que os entrevistadores avaliam
Nao existe resposta certa em system design. Os entrevistadores avaliam: como voce aborda o problema (processo de pensamento), se voce faz as perguntas certas antes de comecar, se considera escalabilidade, disponibilidade e performance, se faz tradeoffs conscientes e os justifica, se comunica de forma clara e estruturada, e se tem conhecimento pratico de tecnologias e componentes.
Um candidato que projeta um sistema simples mas justifica cada decisao e melhor avaliado que um que desenha uma arquitetura complexa sem explicar por que.
Framework ABCD para system design
Uma estrutura de 4 passos que funciona para qualquer pergunta:
A – Ask (Pergunte) — 5 minutos
Antes de desenhar qualquer coisa, faca perguntas para entender os requisitos: quem sao os usuarios? Quantos? Quais as funcionalidades core? Qual a escala esperada (usuarios, requisicoes, dados)? Qual a latencia aceitavel? Precisa ser global ou regional? Qual o nivel de disponibilidade necessario?
Exemplo para “projete o Twitter”: quantos usuarios ativos (DAU)? Qual o tamanho medio de um tweet? Quantos tweets por dia? O feed deve ser em tempo real? Precisamos de search? DMs estao no escopo?
B – Blueprint (Desenhe) — 10 minutos
Desenhe a arquitetura de alto nivel com os componentes principais: clientes (web, mobile), load balancer, servicos/APIs, bancos de dados, cache, filas. Nao entre em detalhes ainda — foque na visao geral e no fluxo de dados.
C – Components (Detalhe) — 15-20 minutos
Aprofunde nos componentes criticos. Para cada um, discuta o esquema de dados (tabelas, indices), a escolha de tecnologia e por que, como escala (particao, replicacao), e como trata falhas.
D – Deep dive (Problemas dificeis) — 5-10 minutos
Discuta desafios especificos do sistema: como garantir consistencia em dados distribuidos? Como lidar com hot spots? Como monitorar e alertar sobre problemas? Como fazer deploy sem downtime?
Problemas classicos e como abordar
Design de um URL Shortener (dificuldade: facil)
Escala: 100M URLs, 10K creates/dia, 100K reads/seg. Componentes: API REST (POST /shorten, GET /:hash), gerador de hash (Base62 de counter auto-incrementante), banco NoSQL (DynamoDB: hash -> original_url), cache Redis (top 20% URLs = 80% trafego). Tradeoff: counter sequencial vs hash aleatorio (sequencial e mais eficiente mas revela informacao sobre volume).
Design de um Chat System (dificuldade: media)
Protocolos: WebSocket para mensagens em tempo real (bidirecional), HTTP para requests tradicionais (login, historico). Componentes: WebSocket Gateway (mantém conexoes ativas), Message Service (processa e armazena mensagens), Presence Service (online/offline/typing), Notification Service (push para usuarios offline). Storage: banco para historico de mensagens (Cassandra — otimizado para writes), Redis para presenca e sessoes. Desafio: user em multiplos dispositivos (sincronizar estado), ordenacao de mensagens (Lamport timestamps), entrega garantida (ack por mensagem).
Design de um Rate Limiter (dificuldade: facil-media)
Algoritmos: Token Bucket (mais usado — cada usuario recebe N tokens por intervalo), Sliding Window Log (mais preciso, mais memoria), Fixed Window Counter (simples, porem vulneravel a picos na borda da janela). Implementacao: Redis com INCR e EXPIRE para janela fixa. Lua script para operacao atomica. Headers HTTP: X-RateLimit-Remaining, X-RateLimit-Reset.
Dicas praticas para a entrevista
Pense em voz alta: o entrevistador quer ver seu raciocinio, nao apenas o resultado final. Comece pelo caso simples: comece com um servidor unico e depois escale. E mais facil do que projetar o sistema distribuido de cara. Use numeros: “10K RPS com 100ms de latencia por request = 1000 conexoes simultaneas = preciso de pelo menos 3 servidores com 500 conexoes cada” — e muito mais impressionante que “preciso de alguns servidores”. Conheca seus numeros de referencia: quanto uma instancia EC2 aguenta? Quanto uma query SQL leva? Qual a latencia de uma chamada de rede?
Recursos de estudo
System Design Interview (Alex Xu): vol. 1 e 2, os livros mais recomendados. Designing Data-Intensive Applications (Martin Kleppmann): para entender os fundamentos profundamente. ByteByteGo no YouTube: explicacoes visuais excelentes. Exercite: pegue sistemas que voce usa (Spotify, Uber, Instagram) e tente projetar a arquitetura. Confira tech blogs de empresas (Netflix, Uber, Nubank, Spotify) para decisoes arquiteturais reais.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
