System Design — Cola de Entrevista

Tracking de Eventos · Grupo SBF (Centauro / Nike) · 60 min

imprima esta página · A4 · 1 folha

📐 Estimativa de bolso — abra com isto

~15 mi

visitantes/mês

~20

eventos/sessão

~300 mi

eventos/mês

~115/s

média

~1700/s

pico (15× média)

🏗️ 5 Camadas — desenho em ordem

Cliente / Storefront

Storefront VTEX IO · Event SDK / Pixel · dataLayer / GTM (GA4) · Batching + sendBeacon

Coleta / Ingestão

CDN / Edge · API Gateway / LB · Collector /collect · Consent LGPD gate

Streaming / Processamento

Kafka (partition por session_id) · Stream Processor (Flink) · Schema Registry

Armazenamento

Data Lake — S3 (raw, imutável) · OLAP — ClickHouse (hot path) · Data Warehouse (cold path)

Consumo

Dashboards ao vivo · BI / Analytics · ML / Recomendação · A/B Testing

Transversal (vale para todas)

CI/CD — GitHub Actions
IaC — Terraform
Observabilidade — logs · métricas · traces · SLO
Segurança & LGPD — consent · PII · retention
Qualidade — Playwright · k6 (carga)

❓ 6 perguntas no início (0-10min)

Volume esperado em eventos/segundo no pico (Black Friday)?
Perda de evento é tolerável? Qual latência aceitável?
Eventos alimentam operação em tempo real ou só análise?
Quem consome — marketing, BI, ML, todos?
Restrição de cloud, custo, ou requisito LGPD específico?
Aproveito GTM/GA já existente ou construo do zero?

⏱️ Cronograma 60min

0–10 min	Requisitos & estimativas — faça as 6 perguntas, estime eventos/s
10–20 min	Desenho de alto nível — 5 caixas-camada de cima para baixo
20–40 min	Aprofundar 2–3 pontos — contrato de evento, broker+processor, OLAP
40–50 min	Camada transversal — CI/CD, IaC, testes E2E + carga, observabilidade
50–60 min	Trade-offs & gargalos — "se X triplicar, mitigação Y, risco Z"

⚖️ 8 Trade-offs essenciais

Idempotência

event_id (UUID) gerado no cliente · dedupe no processor com state TTL · resolve at-least-once do broker

Hot vs Cold path

OLAP em segundos (operação) · Lake → Warehouse em batch (análise) · Lambda/Kappa

Schema versionado

Schema Registry + data contract · backward compatibility · valida antes de publicar

Ordenação & relógio

client_timestamp + server_timestamp · event time + watermark de 30s na sessionização

Resiliência cliente

sendBeacon (sobrevive ao unload) + queue local + retry backoff exponencial

Escala & pico

Partition por session_id · autoscaling collector · back-pressure no broker

Amostragem

só sob pico extremo · NUNCA amostrar purchase · sample por hash de session_id

LGPD

consent gate antes de coletar · anonimização de PII · retention via S3 lifecycle

💬 Frases prontas — solte ao desenhar

O evento já nasce com event_id (UUID) — idempotência resolvida.
sendBeacon + batching: não perco evento se a aba fechar.
Collector responde 204 e segue a vida — stateless, escala horizontal.
Kafka particionado por session_id desacopla produção de consumo e absorve picos.
Flink faz enrichment, sessionização (event time + watermark) e dedupe (event_id).
Raw imutável no Lake = posso fazer replay quando uma regra mudar.
ClickHouse colunar = agregações em segundos sobre bilhões de linhas.
Se o pico triplicar, gargalo é o processor — mitigo com mais partições e amostrando eventos de baixo valor.

🔑 Palavras-chave por categoria

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 · warehouse · hot/cold path · Lambda/Kappa

Frontend / VTEX

VTEX IO · Pixel App · Store Framework · dataLayer · GA4

Infra & QA

GitHub Actions · Terraform · k6 · Playwright · SLO