System Design Interview Para Desenvolvedor Sênior: Como Passar

# System Design Interview Para Desenvolvedor Sênior: Como Passar A system design interview é a mais diferenciadora das etapas de Big Tech. É ela que separa engenheiros de nível sênior dos demais — e é a que mais candidatos brasileiros subestimam na preparação. Diferente do coding interview onde existe uma resposta certa, no system design você precisa demonstrar como pensa sobre escalabilidade, trade-offs e problemas reais de engenharia. ## O Que É Avaliado em System Design As empresas avaliam sua capacidade de: 1. **Clarificar requisitos** — fazer as perguntas certas antes de desenhar qualquer coisa 2. **Estimar escala** — raciocinar sobre throughput, latência e armazenamento 3. **Projetar soluções escaláveis** — load balancers, caches, databases, filas de mensagem 4. **Identificar pontos críticos** — single points of failure, gargalos 5. **Discutir trade-offs** — não existe "melhor arquitetura", existe "melhor para esse contexto" ## O Framework RADIO Para System Design RADIO é o framework mais completo para estruturar sua resposta: **R — Requirements (Requisitos)** Sempre comece clarificando requisitos funcionais e não-funcionais: *Funcionais:* O que o sistema deve fazer? - "Usuários podem criar posts" - "Usuários podem seguir outros usuários" - "Feed mostra posts dos usuários seguidos" *Não-funcionais:* Como o sistema deve se comportar? - "Disponibilidade: 99.9% uptime" - "Latência: < 200ms para 95% das requests" - "Escala: 10 milhões de usuários ativos" **A — API Design** Defina os endpoints principais antes de entrar na arquitetura. Isso estabelece o contrato do sistema: ``` POST /posts → cria post GET /feed → retorna feed do usuário autenticado POST /follow/{userId} → segue usuário ``` **D — Data Model** Quais entidades existem? Quais são as relações? Que tipo de banco de dados faz sentido? **I — High-Level Design** Desenhe os componentes principais: client → CDN → load balancer → app servers → database. **O — Optimize / Deep Dive** Escolha 1-2 componentes para aprofundar. Onde estão os gargalos? Como escalar? ## Os Problemas Mais Comuns em Entrevistas ### 1. Design a URL Shortener (bit.ly) **Requisitos típicos:** 100M URLs criadas/dia, 10B redirects/dia **Solução de alto nível:** - Hash da URL original (MD5, truncado) para gerar o short code - Banco de dados chave-valor (Redis/DynamoDB) para lookup ultra-rápido - CDN na frente para cache dos redirects mais frequentes - Separação de leitura/escrita — reads são 100x mais frequentes **Trade-offs a discutir:** - Base62 vs MD5 para geração de IDs - Colisão de hashes: como detectar e resolver - TTL das URLs: como implementar expiração ### 2. Design a News Feed (Facebook/Twitter feed) **Requisitos típicos:** 500M usuários, pessoa média segue 200 pessoas **Duas abordagens:** - **Pull model:** Quando usuário abre o feed, busca posts de todos que segue em tempo real. Problema: lento para usuários com muitos seguidos. - **Push model (fan-out on write):** Quando alguém posta, o post é escrito no feed de todos os seguidores. Problema: celebridades com 10M seguidores criam 10M escritas. - **Solução híbrida:** Push para usuários normais, pull para celebridades. ### 3. Design a Distributed Cache (Redis-like) **Eviction policies:** LRU, LFU, TTL **Consistência:** Write-through, write-back, write-around **Sharding:** Consistent hashing para distribuir dados entre nós **Replication:** Leader-follower para alta disponibilidade ### 4. Design a Video Streaming Platform (YouTube) **Upload pipeline:** Client → Upload service → Message queue → Transcoding workers → CDN **Streaming:** Adaptive bitrate (ABR), segmentos HLS/DASH **Storage:** Metadata no banco relacional, vídeos no object storage (S3) **CDN:** Edge caching para conteúdo popular, origin pull para conteúdo raro ## Números Para Memorizar Ter noção de capacidades é crucial para estimativas credíveis: | Operação | Latência típica | |----------|-----------------| | L1 cache hit | 0.5 ns | | L2 cache hit | 7 ns | | RAM read | 100 ns | | SSD random read | 150 µs | | Network round trip (mesmo DC) | 500 µs | | HDD seek | 10 ms | | Network round trip (EUA→Europa) | 150 ms | | Dado | Tamanho típico | |------|----------------| | Tweet/post curto | 1 KB | | Foto de perfil | 100 KB | | Foto do Instagram | 3 MB | | Vídeo 1 minuto | 150 MB | Para estimativas: 1 servidor = ~50K requests/segundo com caching. ## Como Se Comportar Durante a Entrevista **Pense em voz alta sempre.** O entrevistador quer ver seu processo, não apenas a conclusão. Se ficar em silêncio por 2 minutos, isso é ruim mesmo que a solução final seja boa. **Não vá fundo demais muito cedo.** Um erro comum é começar a detalhar o banco de dados antes de ter o design de alto nível aprovado. Desenhe o quadro geral primeiro, então peça ao entrevistador qual componente você deve aprofundar. **Proponha e justifique trade-offs.** "Podemos usar SQL ou NoSQL aqui. SQL nos dá ACID e queries flexíveis, mas NoSQL escala melhor horizontalmente. Para esse caso com 10B reads/dia, eu escolheria NoSQL. Você concorda ou quer explorar SQL?" **Adapte ao entrevistador.** Alguns entrevistadores querem um design abrangente, outros querem profundidade em um subsistema. Leia as perguntas e comentários deles. Para praticar system design em português com feedback detalhado, use o **[Mock Interview do VagaNaGringa](https://vaganagringa.dev/mock-interview/)** — simula entrevistas de system design com o mesmo padrão das Big Techs.