System Design — Como Conduzir a Entrevista
Ordem de desenho em 60 min, perguntas para fazer no início, palavras-chave para soltar, frases prontas.
Definição
O System Design Interview tem 60 minutos. Estrutura: (0-10) Requisitos + estimativas — faça perguntas, pegue volume, defina funcional vs não-funcional. (10-20) Desenho de alto nível — 5 caixas-camada de cima para baixo com setas claras. (20-40) Aprofundar 2-3 pontos — contrato de evento, broker+processor, modelo OLAP. (40-50) Camada transversal — CI/CD, IaC, testes E2E + carga, observabilidade, SLOs. (50-60) Trade-offs e gargalos — "se X triplicar, mitigação Y; risco Z".
Problema → Solução
Problema
Candidatos sem framework saem desenhando direto: pulam estimativas, fazem perguntas tarde demais, esquecem camada transversal, terminam sem falar trade-off. Resultado: entrevistador conclui "fala de tecnologia mas não pensa em arquitetura".Solução
Siga a ordem cronológica. Anote o tempo. Termine cada parte com "antes de continuar, alguma pergunta?". Use palavras-chave específicas (não genéricas): "Kafka particionado por session_id" > "uma fila". "ClickHouse com materialized view" > "um banco de analytics". Mostre vocabulário.Dica de entrevista
Tip
Faça as 6 perguntas iniciais antes de desenhar nada: volume? perda tolerável? latência? consumidores? cloud preferida? GTM/GA existente? Mesmo que o entrevistador não responda tudo, você demonstrou raciocínio estruturado em 1 minuto. Isso vale ouro.Código
// Cronograma de 60 minutos no whiteboard
// ── 0-10 min: REQUISITOS + ESTIMATIVAS ────────────────────────
// Faça as 6 perguntas. Anote no canto:
// • Volume: ~115/s média, ~1700/s pico
// • Latência: dashboard em segundos
// • LGPD: consent obrigatório
// • Stack: VTEX IO + AWS
// ── 10-20 min: DESENHO DE ALTO NÍVEL ──────────────────────────
// 5 caixas-camada, setas claras
// [Cliente] → [Coleta] → [Streaming] → [Armazenamento] → [Consumo]
// ↑
// [Transversal: CI/CD, Obs, LGPD]
// ── 20-40 min: APROFUNDAR 3 PONTOS ────────────────────────────
// 1. Contrato de evento (event_id, schema GA4)
// 2. Broker + Processor (Kafka partition + Flink dedupe + session)
// 3. Modelo OLAP (ClickHouse + materialized view)
// ── 40-50 min: CAMADA TRANSVERSAL ─────────────────────────────
// • CI/CD: GitHub Actions
// • IaC: Terraform
// • Observabilidade: logs + métricas + traces + SLO
// • Testes: Playwright E2E + k6 carga (simula 5x pico)
// • Segurança: consent + anonimização + retention
// ── 50-60 min: TRADE-OFFS + GARGALOS ──────────────────────────
// "Se o pico triplicar, gargalo é Flink. Mitigo com mais partições.
// Risco: schema drift. Mitigo com Registry + alerta.
// Custo do OLAP cresce com cardinalidade — TTL de 90 dias."Perguntas de entrevista
Q.Quais as 6 perguntas obrigatórias no início?▾
A.(1) Volume esperado em eventos/segundo no pico (Black Friday)? (2) Perda de evento é tolerável e qual a latência aceitável? (3) Operação em tempo real ou só análise posterior? (4) Quem consome — marketing, BI, ML, todos? (5) Restrição de cloud, custo ou requisito LGPD? (6) Aproveito GTM/GA existente ou construo do zero?
Q.Quais palavras-chave demonstram senioridade?▾
A.Pipeline: event pipeline, collector, sendBeacon, batching, ingestion. Streaming: Kafka, partition, back-pressure, Flink, sessionização, watermark, event time. Confiabilidade: idempotência, event_id, dedupe, schema registry, data contract. Dados: data lake, OLAP, ClickHouse, hot/cold path, Lambda/Kappa. Frontend/VTEX: VTEX IO, Pixel App, dataLayer, GA4. Infra: GitHub Actions, Terraform, k6, Playwright, SLO.
Q.Como fechar a entrevista de forma forte?▾
A."Resumindo os trade-offs: (1) Para resiliência, sendBeacon + idempotência por event_id. (2) Hot path em ClickHouse (segundos), cold path em Lake/Warehouse (batch). (3) Schema Registry para evolução sem quebrar. Se o pico triplicar, o gargalo é o processor; mitigação: scale Flink + amostrar eventos de baixo valor. Riscos: schema drift, perda de evento em rede instável, custo do OLAP em alta cardinalidade."
110/122← →