tema
System design
Não existe resposta certa em system design — existe raciocínio explícito. O entrevistador quer ver como você navega trade-offs: consistência vs. disponibilidade, latência vs. custo, simplicidade vs. escala futura. Comece sempre pelos requisitos antes de desenhar caixas.
Simuladores de System design
Principais perguntas de System design
ver todas →Desenhe um encurtador de URLs
KV store código→URL, geração via contador base62 ou hash truncado, cache na frente pra leitura pesada.
MédioPlenoEstratégias de load balancing
Round robin (simples), least connections (carga desigual), IP hash (sessão sticky) — depende do estado da app.
MédioPlenoCache-aside vs. write-through
Cache-aside aceita dado stale por uma janela; write-through mantém consistência ao custo de escrita mais lenta.
MédioPlenoO que o teorema CAP realmente diz
Na prática a escolha é CP vs. AP durante uma partição — P é inevitável em sistemas distribuídos.
DifícilSêniorAlgoritmos de rate limiting
Token bucket permite rajadas controladas e é barato; sliding window é mais preciso mas mais caro.
DifícilSêniorComo escolher uma chave de sharding
Escolha uma chave com distribuição uniforme e que mantenha dados relacionados juntos; cuidado com hot shards e queries cross-shard.
DifícilSêniorQuando usar uma fila de mensagens
Use fila para desacoplar produtor e consumidor no tempo e absorver picos — troca resposta imediata por consistência eventual.
MédioPlenoDesenhe um feed de notícias estilo timeline
Fan-out na escrita é rápido de ler mas caro de escrever para contas grandes; sistemas reais usam um híbrido.
DifícilSêniorComo começar uma pergunta aberta de system design
Clarificar escopo e cortar features; requisitos funcionais e não-funcionais COM números; contas de guardanapo (QPS, storage); só então API e diagrama. Prioriza e estima antes de desenhar.
MédioPlenoFan-out on write x fan-out on read pra timeline
Write/push: pré-escreve o post na caixa de cada seguidor (leitura barata, celebridade explode). Read/pull: mescla na leitura (escrita barata, leitura cara). Híbrido: push pra comuns, pull pra celebridades.
DifícilSêniorEntrega 'pelo menos uma vez' e consumidores idempotentes
A mensagem pode chegar repetida (retry, rebalance). O consumidor tem que ser idempotente: chave de dedupe com TTL, operações do tipo 'set' em vez de 'incrementa', ou inbox transacional.
DifícilSêniorRéplicas de leitura e o lag de replicação
Réplicas ficam atrás da primária (replicação assíncrona). Quebra 'read your own writes'. Roteie leitura pós-escrita pra primária por uma janela, ou leia da primária só onde a consistência importa.
MédioPlenoCircuit breaker e falha em cascata
Dependência lenta faz o chamador esgotar recursos esperando e falhar tudo (cascata). O breaker abre após erros demais e falha rápido / usa fallback, liberando recursos e dando a dependência tempo de recuperar.
DifícilSêniorO que uma CDN resolve (e o que ela não resolve)
Serve conteúdo cacheável perto do usuário: menos latência, menos carga na origem, mitiga DDoS. Não resolve: conteúdo personalizado, invalidação instantânea, cache miss, e nada do backend/escrita.
MédioPleno
Perguntas frequentes
O que os entrevistadores mais avaliam em system design?
Não existe resposta certa em system design — existe raciocínio explícito. O entrevistador quer ver como você navega trade-offs: consistência vs. disponibilidade, latência vs. custo, simplicidade vs. escala futura. Comece sempre pelos requisitos antes de desenhar caixas.
Quanto tempo leva pra treinar system design até me sentir pronto?
Depende do seu ponto de partida, mas a maioria sente diferença depois de 2-3 simulações completas com revisão das perguntas erradas — é aí que os padrões que se repetem em entrevista real ficam visíveis.