Framework de Design
The 4-Step Framework:
- 1. Clarify Requirements (5 min)
- Quais features exatamente precisamos?
- Scale? (users, requests/sec, data size)
- Latência aceitável?
- Consistency vs Availability (CAP theorem)?
- 2. High-Level Architecture (10 min)
- Client → API → Services → DB/Cache
- Quais databases? Quais services?
- 3. Deep Dive (15 min)
- Trade-offs específicos
- Bottlenecks e como resolver
- Scaling strategies
- 4. Wrap Up (5 min)
- Monitoring e alerting
- Error handling
- Cost considerations
Trade-offs Comuns:
- Consistency vs Availability: CAP theorem - escolha baseado no uso
- Read vs Write heavy: Qual optimizar?
- Latency vs Cost: Mais replicas = mais custo
- Simple vs Flexible: KISS vs YAGNI
CAP Theorem: Escolha 2 de 3
CAP THEOREM: A ESCOLHA IMPOSSÍVEL
CONSISTENCY
/\
/ \
/ \
/ CA \
/ / \
/ CP AP\
/ \ / \
AVAILABILITY PARTITION TOLERANCE
C: Todos veem os mesmos dados ao mesmo tempo
A: Todo request recebe resposta
P: Funciona mesmo se rede falha
Partições ACONTECEM! Escolha real:
CP: Zookeeper, HBase, Redis Cluster (transações financeiras)
AP: Cassandra, DynamoDB, CouchDB (dados eventually consistent)
Escalabilidade
Scaling Patterns:
- Vertical Scaling: Mais poder (CPU, RAM) - limite físico
- Horizontal Scaling: Mais máquinas - complexo, precisa stateless
- Load Balancing: Round-robin, least connections, IP hash
- Database Sharding: Dividir dados em múltiplos DBs
- Read Replicas: Réplicas para leitura
Latência Real: A Velocidade da Luz
Dados não viajam mais rápido que a luz. Isso importa para sistemas distribuídos:
A VELOCIDADE DA LUZ IMPORTA!
Velocidade da luz: ~300.000 km/s em fibra (~200.000 km/s efetiva)
Distância e latência:
SP → NY (~7.700 km) → ~100-150ms real
SP → Tóquio (~18.000 km) → ~250-300ms real
Mesmo DC → ~0.5-2ms
1 operação cross-region = 50-100x mais lenta que local!
Estratégia: Colocar dados perto dos usuários (CDN, edge)
Throughput vs Latência
LATÊNCIA vs THROUGHPUT
Latência: tempo para UMA requisição (P50, P95, P99)
Throughput: requisições por segundo (RPS)
Exemplo:
• Latência 100ms → max 10 req/s por thread
• Latência 10ms → max 100 req/s por thread
Se 1000 usuários simultâneos:
• Com 10 conexões: 990 esperam na fila!
Métricas:
• P50: 10ms (mediana)
• P95: 50ms (95% das req < 50ms)
• P99: 100ms (99% das req < 100ms)
Stateless vs Stateful:
// STATELESS (fácil de scale):
{ user_id, data } → stateless service
// STATEFUL (difícil de scale):
{ session_id, connection, local_cache }
// Precisa de sticky sessions ou external state
{ user_id, data } → stateless service
// STATEFUL (difícil de scale):
{ session_id, connection, local_cache }
// Precisa de sticky sessions ou external state
Metrics importantes:
- Requests per second (RPS): throughput
- Latência P50/P95/P99: distribuição de latência
- Error rate: 4xx, 5xx
- CPU/Memory usage: capacidade
Databases
SQL vs NoSQL:
| Característica | SQL | NoSQL |
|---|---|---|
| Schema | Fixo/Declarado | Flexible |
| Queries | Complexas (JOINs) | Simples (key-value, map-reduce) |
| Transactions | ACID completo | Eventual consistency |
| Escala | Vertical + Sharding | Horizontal nativo |
| Exemplos | PostgreSQL, MySQL | MongoDB, Cassandra, Redis |
Quando usar cada tipo:
- SQL: Dados estruturados, relações complexas, transações
- Key-Value (Redis): Cache, sessions, leaderboards
- Document (MongoDB): Dados semi-estruturados,schema
- Wide-column (Cassandra): Time-series, write-heavy
- Graph (Neo4j): Relations complexas, redes sociais
Caching
Caching Strategies:
- Cache-aside: App verifica cache → miss → busca DB → popula cache
- Read-through: Cache busca automaticamente no DB
- Write-through: Escreve no cache E no DB
- Write-back: Escreve no cache, DB depois (risco de perda)
Cache Hit Ratio e Seu Impacto
CACHE HIT = 10x MAIS THROUGHPUT!
Sem cache: 10.000 req/s = 100 segundos de trabalho
Com 90% hit: 10.000 req/s = 10 segundos de trabalho!
Hit Rate Speedup Reqs/seg por CPU
0% 1x ~100 req/s
50% 2x ~200 req/s
90% 10x ~1.000 req/s
99% 100x ~10.000 req/s
Regra: Cada 9 no hit rate = 10x mais throughput!
Cache Invalidation: O Problema Difícil
"There are only two hard things: cache invalidation and naming things."
ESTRATÉGIAS DE INVALIDAÇÃO
1. Write-through + Write-around:
• Escreve no DB, invalida cache
• Risco: dados temporariamente inconsistentes
2. Write-through + Write-behind:
• Escreve no cache, async para DB
• Rápido, mas risco de perda de dados
3. TTL (Time To Live):
• Dados expiram automaticamente
• Simples, mas pode ter dados stale
• Bom para dados que mudam raramente
Práticas:
• TTL curto (30-60s) para dados dinâmicos
• Event-driven invalidation quando DB muda
• Versionamento de cache (key inclui versão)
Eviction Policies:
- LRU (Least Recently Used): Mais comum
- LFU (Least Frequently Used): Baseado em frequência
- FIFO: First in, first out
- TTL: Time to live - expire automático
Redis Use Cases:
- Session store (autenticação)
- Cache de queries frequentes
- Rate limiting (sliding window)
- Leaderboards / rankings
- Message queues (pub/sub)
- Distributed locks
Designs Práticos
Design URL Shortener
Medium
tinyurl.com - de 100B URLs únicas. Como gerar short URLs únicas?
Design Rate Limiter
Medium
Limit 100 req/min por IP. Como implementar em sistema distribuído?
Design Twitter
Hard
Newsfeed, timeline, trending topics. 300M users, 500M tweets/day.
O Problema do Fan-out:
Quando usuário com 1M seguidores posta tweet:
Fan-out on write (ativo):
• Push para 1M timelines = MUITO lento!
• 1M writes em 1 segundo? Impossível!
Fan-out on read (passivo):
• Quando usuário abre app, busca tweets dos que segue
• Qual tweet de quais pessoas? Muita computação...
Solução híbrida:
• Seguidores < 10K: fan-out on write (push)
• Seguidores > 10K: fan-out on read (pull)
Timeline do usuário = mix de:
• Pull: tweets de famous people (celebridades)
• Push: tweets de contas normais
Cache de timeline:
• Redis sorted set: {tweet_id, timestamp}
• Guarda últimos 800 tweets por usuário
• Atualização rápida quando chega tweet push
Design Uber
Hard
Real-time driver matching, surge pricing, GPS tracking.
Design Video Streaming
Hard
Netflix/YouTube - como transmitir vídeo em escala?
Design Chat System
Medium
WhatsApp - mensagens em tempo real, online status.