Guia de entrevista de design de sistema 2026: estruturas, padrões e estudos de caso

As entrevistas de design de sistemas são os guardiões dos cargos de engenharia sênior nas principais empresas de tecnologia. Eles testam sua capacidade de projetar sistemas escalonáveis ​​e confiáveis ​​sob requisitos ambíguos. Este guia cobre as estruturas, padrões e exemplos reais de que você precisa para acertá-los em 2026.

A estrutura da entrevista

Cada entrevista de design de sistema segue uma estrutura semelhante. Use esta estrutura de 45 minutos:

• 1-5 minutos— Esclarecer requisitos, definir escopo
• 5-10 minutos— Escala estimada (usuários, QPS, armazenamento)
• 10-20 minutos— Design de alto nível, componentes principais
• 20-35 minutos— Aprofundamento em componentes críticos
• 35-45 minutos— Escala, gargalos, compensações

Etapa 1: esclarecer os requisitos

Nunca comece a projetar antes de fazer estas perguntas:

• Quem são os usuários? O que eles precisam fazer?
• Quais são os recursos principais versus os recursos interessantes?
• Quantos usuários? Muita leitura ou muita gravação?
• Qual é a latência necessária? Qual é o requisito de consistência?
• Qual é o volume de dados esperado? Por quanto tempo os dados são retidos?

Etapa 2: estimativa de capacidade

Matemática aproximada que sinaliza maturidade em engenharia:

Example: Design Twitter-like feed

Users: 500M total, 100M daily active (DAU)
Tweets: 100M DAU × 5 tweets/day = 500M tweets/day
Reads: 100M DAU × 100 timeline views/day = 10B reads/day

QPS (writes): 500M / 86400 ≈ 5,800 tweets/sec (peak 3x = 17,000)
QPS (reads): 10B / 86400 ≈ 115,000 reads/sec (peak 3x = 345,000)

Storage (tweets):
- 500M tweets/day × 280 bytes = 140 GB/day
- 5 years = 140 × 365 × 5 ≈ 255 TB of tweet data

Media storage: 10% of tweets have images (100MB avg)
50M tweets/day × 100KB thumbnail = 5 TB/day thumbnail storage

Padrões de design principais

1. Seleção de banco de dados

Escolha o banco de dados certo para o trabalho:

• Relacional (PostgreSQL, MySQL)— Transações ACID, consultas complexas, dados financeiros
• Documento (MongoDB)— esquema flexível, dados aninhados, gerenciamento de conteúdo
• Valor-chave (Redis, DynamoDB)— cache, armazenamento de sessão, pesquisas O(1)
• Coluna larga (Cassandra, HBase)– séries temporais, com muitas gravações em grande escala
• Gráfico (Neo4j)— gráficos sociais, mecanismos de recomendação
• Pesquisa (Elasticsearch)— pesquisa de texto completo, análise de log

2. Estratégia de cache

Cache-Aside (Lazy Loading):
  App → cache miss → DB → write to cache → return

Write-Through:
  App → write to cache AND DB simultaneously

Write-Back (Write-Behind):
  App → write to cache → async write to DB (faster, risk data loss)

Read-Through:
  Cache handles DB fetching automatically (used by Redis+Memcached)

Cache Eviction Policies:
  LRU  — Least Recently Used (most common)
  LFU  — Least Frequently Used
  TTL  — Time-To-Live expiry

3. Balanceamento de carga

Distribua o tráfego entre servidores:

• Rodada Robin– distribuição igual, simples
• Menos conexões— rota para o servidor com menos conexões ativas
• Hash de IP— sessões fixas baseadas no IP do cliente
• Ponderado— distribuir com base na capacidade do servidor

Ferramentas: AWS ALB, Nginx, HAProxy, Envoy, Cloudflare

4. Dimensionamento de banco de dados

Vertical Scaling: Bigger machine (CPU, RAM, SSD)
  Pros: Simple, no code changes
  Cons: Limits, single point of failure, expensive

Read Replicas: Primary handles writes, replicas handle reads
  Pros: Read scalability, disaster recovery
  Cons: Replication lag (eventual consistency)

Sharding (Horizontal Partitioning):
  Split data across multiple DBs by key

  Hash-based: shard = hash(user_id) % num_shards
    Pros: Even distribution
    Cons: Hard to add shards (resharding)

  Range-based: shard by date range or ID range
    Pros: Range queries efficient, easy to add new shards
    Cons: Hot spots (most recent shard gets all writes)

  Directory-based: lookup table maps keys to shards
    Pros: Flexible
    Cons: Lookup overhead, single point of failure

Estudo de caso: Encurtador de URL de design (bit.ly)

Requisitos

Funcional: encurtar URL, redirecionar na visita, aliases personalizados, expiração
Não funcional: latência de leitura de 100 ms, 100 milhões de URLs/gravações por dia, 10 bilhões de leituras/dia

Estimativa de escala

Gravações: 100 milhões/dia = 1.200 QPS (pico 3.600)
Leituras: 10B/dia = 115.000 QPS (pico 345.000) —leitura pesada 100:1
Armazenamento: 100M × 500 bytes = 50 GB/dia × 5 anos = ~90 TB

Design de alto nível

Client → Load Balancer → Web Servers → Cache (Redis)
                                          ↓ cache miss
                                       Database (PostgreSQL + replicas)

URL Shortening API:
  POST /api/shorten
  { "url": "https://very-long-url.com/path", "alias": "mylink", "expires_at": "2027-01-01" }
  → { "short_url": "https://bit.ly/abc123" }

Redirect API:
  GET /{short_code}
  → 301/302 redirect to original URL

Key Generation:
  Option 1: Base62 hash of MD5(url) — take first 7 chars
  Option 2: Counter + Base62 encode (guaranteed unique)
  Option 3: Pre-generate keys in KGS (Key Generation Service)

Esquema de banco de dados

CREATE TABLE urls (
  id           BIGSERIAL PRIMARY KEY,
  short_code   VARCHAR(10) UNIQUE NOT NULL,
  original_url TEXT NOT NULL,
  user_id      BIGINT,
  created_at   TIMESTAMP DEFAULT NOW(),
  expires_at   TIMESTAMP,
  click_count  BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON urls(short_code);
CREATE INDEX idx_user_id ON urls(user_id);

Estudo de caso: Projete um sistema de chat (WhatsApp)

Principais desafios

• Entrega em tempo real— WebSockets para conexões persistentes
• Ordenação de mensagens— números de sequência por conversa
• Entrega off-line— armazena mensagens até que o usuário se reconecte
• Ler recibos– status entregue/lido
• Bate-papo em grupo— distribuição para vários usuários

Architecture:

Client ←→ WebSocket Gateway (stateful) ←→ Message Service
                                              ↓
                                    Message Queue (Kafka)
                                              ↓
                                    Message Store (Cassandra)
                                    - Partitioned by conversation_id
                                    - Ordered by timestamp within partition

Message Flow:
1. User A sends message → WebSocket Gateway (Server A)
2. Gateway publishes to Kafka topic
3. Message Service writes to Cassandra
4. User B's WebSocket Gateway subscribes and delivers
5. If User B offline → push notification via FCM/APNs

Schema (Cassandra - wide column):
  messages_by_conversation
    conversation_id (partition key)
    message_id (clustering key, time-ordered)
    sender_id, content, message_type, created_at

Principais compensações a saber

• SQL versus NoSQL— ACID versus escala, esquema versus flexibilidade
• Consistência vs Disponibilidade— Teorema CAP (prefira AP para social, CP para bancário)
• Puxar vs Empurrar— fan-out na leitura vs fan-out na gravação para feeds
• Monólito vs Microsserviços— simplicidade vs escalabilidade/autonomia da equipe
• Síncrono vs Assíncrono— latência vs taxa de transferência/resiliência
• Consistência Forte vs Eventual– correção vs disponibilidade

Tópicos comuns de design de sistema (2026)

1. Encurtador de URL
2. Twitter/Feed Social
3. WhatsApp/Mensageiro
4. Instagram/Compartilhamento de fotos
5. YouTube/streaming de vídeo
6. Compartilhamento de Uber/passeio
7. Airbnb/Sistema de Reservas
8. Pesquisa Google
9. Limitador de taxa
10. Cache Distribuído (Redis)
11. Sistema de Notificação
12. Rastreador da Web
13. Métricas/Monitoramento (Prometheus)
14. Fila de mensagens distribuídas (Kafka)

As entrevistas de design de sistema recompensam a comunicação clara, o pensamento estruturado e a consciência das compensações em vez de respostas perfeitas. Pratique projetar de 2 a 3 sistemas do zero a cada semana e sempre faça perguntas esclarecedoras antes de desenhar uma única caixa.