System Design Interview: Como Passar nas Entrevistas das Big Techs em 2026

O Que é System Design Interview e Por Que é Crítica

A System Design Interview (entrevista de design de sistemas) é uma das etapas mais temidas e eliminatórias em processos seletivos de Big Tech. Diferente das entrevistas de algoritmos, aqui não existe uma resposta certa — o entrevistador avalia seu processo de pensamento, sua capacidade de fazer trade-offs e sua comunicação técnica.

Para cargos de nível pleno e acima no Google, Meta, Amazon, Microsoft e Netflix, a system design é obrigatória — e frequentemente o motivo de reprovação de candidatos tecnicamente fortes.

O Framework em 6 Etapas

Use este framework em toda system design interview. Cada etapa tem um tempo recomendado para entrevista de 45 minutos:

1. Clarificar Requisitos (5 min)

Nunca comece a desenhar sem entender o escopo. Perguntas essenciais:

• Quantos usuários ativos por dia/mês?
• Qual o volume de operações de leitura vs escrita?
• Qual a latência aceitável para as operações principais?
• O sistema precisa ser global ou por região?
• Quais features são obrigatórias vs opcionais para esta entrevista?

2. Estimativas de Escala (5 min)

Calcule as métricas fundamentais em voz alta:

• DAU (Daily Active Users) × operações por usuário = total de requests/dia
• Divide por 86.400 segundos = QPS (queries per second)
• Pico = 2-3x o QPS médio
• Armazenamento: tamanho médio de um registro × volume total
• Bandwidth: tamanho médio × QPS

3. High-Level Design (10 min)

Desenhe a arquitetura de alto nível: clients → load balancer → app servers → cache → database. Defina os principais componentes antes de entrar em detalhes.

4. Deep Dive nos Componentes Críticos (15 min)

O entrevistador vai guiar para onde aprofundar. Geralmente: o banco de dados, o sistema de cache, ou o componente mais complexo do sistema.

5. Trade-offs e Bottlenecks (7 min)

Discuta proativamente os pontos fracos do seu design: onde está o single point of failure? Como escalar horizontalmente? Qual o plano de disaster recovery?

6. Perguntas e Refinamentos (3 min)

Demonstre curiosidade sobre como o sistema real foi construído na empresa.

Sistemas Mais Cobrados: Os 10 Clássicos

1. URL Shortener (tipo bit.ly)

Conceitos: geração de hash curto, redirecionamento 301 vs 302, cache de alta leitura (Redis), banco de dados de mapeamentos. Scale: 100:1 read/write ratio — use read replicas e cache agressivo.

2. Twitter Feed / News Feed

O mais complexo. Fan-out on write vs fan-out on read. Para celebridades (many followers): fan-out on read. Para usuários normais: fan-out on write para cache. Combine as abordagens (Instagram faz isso).

3. WhatsApp / Chat System

WebSockets para conexões persistentes. Message queues para entrega garantida. Armazenamento de mensagens (Cassandra para write-heavy). Presence system (Redis com TTL).

4. YouTube / Netflix (Video Streaming)

Upload pipeline: chunking → transcoding → CDN distribution. Streaming: adaptive bitrate (HLS/DASH). Metadados separados do conteúdo binário. CDN global para latência baixa.

5. Uber / Ride Sharing

Geospatial indexing (quadtrees ou S2 library). Real-time location updates (WebSockets). Matching algorithm. Surge pricing system. Dois serviços distintos: driver service e rider service.

6. Google Search Autocomplete

Trie data structure para sugestões. Top-K queries armazenadas em cada nó. Distributed trie para escala. Zookeeper para coordenação.

7. Rate Limiter

Algoritmos: token bucket, leaky bucket, sliding window log, sliding window counter. Redis + Lua scripts para operações atômicas distribuídas. Retorna 429 Too Many Requests.

8. Distributed Cache (tipo Redis)

Cache eviction policies: LRU, LFU, TTL. Consistent hashing para distribuição. Replicação master-slave. Cache-aside vs write-through vs write-behind patterns.

9. Notification System

Push (mobile: APNS/FCM), email, SMS — múltiplos canais. Message queue (Kafka) para desacoplamento. Retry logic com dead letter queue. Priorização de notificações críticas.

10. Web Crawler

BFS com priority queue. Politeness delay por domínio. Distributed crawling com URL frontier. Deduplicação de conteúdo (SimHash). Robots.txt compliance.

Conceitos Fundamentais Que Você Precisa Dominar

• CAP Theorem: Consistency, Availability, Partition Tolerance — escolha 2
• SQL vs NoSQL: quando usar cada um e por quê
• Horizontal vs Vertical Scaling: trade-offs práticos
• Consistent Hashing: distribuição de dados e adição de nós
• Replication: leader-follower, multi-leader, leaderless
• Sharding: horizontal partitioning strategies
• CDN: push vs pull, cache invalidation
• Message Queues: Kafka vs RabbitMQ vs SQS
• Load Balancing: L4 vs L7, algoritmos (round robin, least connections)

Erros Mais Comuns na System Design Interview

• Começar a desenhar sem clarificar requisitos — é eliminatório
• Propor solução única sem discutir trade-offs
• Não calcular escala antes de escolher tecnologias
• Overengineering: propor Kubernetes e microservices para sistema simples
• Silêncio: o entrevistador quer ouvir seu raciocínio, não ver o resultado final
• Não conhecer os números: 1 million requests/day = ~12 RPS (não 1 million RPS)

Como Estudar: Plano de 4 Semanas

1. Semana 1: System Design Primer (GitHub) — leia todo o guia, entenda os fundamentos
2. Semana 2: Pratique URL shortener, Twitter feed, WhatsApp — explique em voz alta
3. Semana 3: YouTube, Uber, Google Search — sistemas mais complexos
4. Semana 4: Mock interviews com parceiro ou ferramenta (Pramp, interviewing.io)

Use as resources: Designing Data-Intensive Applications (livro do Kleppmann) para aprofundamento teórico, e os vídeos do canal "Gaurav Sen" e "ByteByteGo" para visual explanations.