Projetando o WhatsApp em Escala Planetária: Guia Completo de System Design

Resumo: Um guia de arquitetura em nível de produção para construir um sistema estilo WhatsApp com conexões persistentes, entrega online/offline, criptografia ponta a ponta, grupos em alta escala, mídia, sincronização multi-dispositivo e operação global.

Publicado: Fevereiro 2026 Tempo de leitura: 95 minutos Palavras-chave: #SystemDesign #WhatsApp #RealtimeMessaging #E2EEncryption #SignalProtocol #SistemasDistribuídos #Escalabilidade #EntrevistaTécnica

Um usuário em São Paulo envia "tô chegando" para um grupo com centenas de membros. Ao mesmo tempo:

• parte do grupo está em rede móvel ruim,
• parte está offline,
• vários usuários têm mais de um dispositivo conectado,
• alguns países estão com latência alta por condições de rede.

Para o usuário, a expectativa é simples: mensagem instantânea e confiável.

Para o sistema, o problema é profundo:

• latência muito baixa,
• consistência prática de entrega,
• fanout massivo em grupos,
• suporte robusto a offline,
• privacidade forte com E2E por padrão.

Sistemas de mensageria em escala não falham por falta de tecnologia. Falham por escolhas ruins de semântica de entrega, ordenação, chaves, e operação durante incidentes.

Este guia cobre esses pontos de forma direta e aplicável.

Sumário

• Análise de Requisitos
• Cálculos de Envelope
• Arquitetura de Alto Nível
• Modelo de Protocolo e Conexão
• Identidade e Trust de Dispositivo (Core 1)
• Ciclo de Vida da Mensagem (Core 2)
• Semântica de Entrega e Ordenação (Core 3)
• Criptografia E2E com Princípios do Signal (Core 4)
• Arquitetura de Grupos (Core 5)
• Pipeline de Mídia (Core 6)
• Sincronização Multi-Dispositivo (Core 7)
• Presence, Typing e Read Receipts (Core 8)
• Push e Entrega Offline
• Spam, Abuse e Safety
• Modelagem de Dados
• Caching e Sharding
• Multi-Região e DR
• Observabilidade e SLOs
• Dicas de Entrevista
• Anti-Patterns
• Conclusão
• Referências
• Referência Rápida

Análise de Requisitos

Antes de falar em WebSocket, Kafka ou Signal, defina o escopo.

Requisitos Funcionais

1. Chat 1:1.
2. Chat em grupo.
3. Estados de mensagem (enviado, entregue, lido).
4. Entrega para usuários offline.
5. Sincronização de histórico no reconnect.
6. Mídia (imagem, vídeo, áudio, docs).
7. Push notifications.
8. Multi-dispositivo por conta.

Requisitos Não-Funcionais

Consistência

Modelo prático:

• transporte at-least-once,
• processamento idempotente,
• ordenação best-effort por conversa,
• consistência eventual para metadata secundária.

Perguntas de Clarificação

1. Ordenação global é obrigatória?
2. E2E para todos os chats?
3. Tamanho máximo de grupo?
4. Quantos dispositivos por conta?
5. Janela de retenção offline?

Premissas deste artigo:

• ordenação por conversa (não global),
• E2E em 1:1 e grupos,
• grupos grandes (até ~1.024 membros),
• até 5 devices por usuário,
• fila offline com retenção de até 30 dias.

Cálculos de Envelope

Escala Assumida

DAU: 1,8 bilhão
Usuários online simultâneos: 350 milhões
Mensagens/dia: 180 bilhões
Participação de grupos: 72%
Mensagens de mídia/dia: 8 bilhões
Pico: 6x

Throughput

Mensagens/s média = 180.000.000.000 / 86.400 ~= 2.083.333
Pico ~= 12.500.000 msg/s

Amplificação de Fanout

Mensagens de grupo multiplicam operações de entrega:

fanout médio efetivo por msg de grupo: 18 destinos
operações de entrega/dia ~= 180B * 0,72 * 18 ~= 2,33 trilhões

Storage Direcional

Se envelope médio for 850 bytes:

180B * 850B ~= 153TB/dia (lógico)
RF=3 => ~459TB/dia

Mídia domina custo em PB/dia, dependendo do perfil de uso.

Insight

O gargalo principal é a combinação de:

1. conexões persistentes,
2. fanout de grupos,
3. filas offline,
4. limites de privacidade por E2E.

Arquitetura de Alto Nível

Separação de Planos

1. Plano de conexão e sessão.
2. Plano de roteamento de mensagens.
3. Plano de mídia.
4. Plano criptográfico.
5. Plano analítico assínc.

Modelo de Protocolo e Conexão

Conexão persistente é essencial para latência e bateria.

Por que Conexão Longa

Handshake por mensagem via HTTP seria lento e caro em mobile.

Padrão:

• TCP/TLS ou QUIC persistente,
• framing binário,
• keepalive adaptativo.

Estado de Conexão

Responsabilidades do Gateway

1. autenticar sessão e dispositivo,
2. registrar mapeamento user/device -> shard,
3. gerenciar heartbeat,
4. aplicar rate limits,
5. encaminhar envelopes para router.

Exemplo de Chaves de Sessão

session:user:123:device:ios-main -> gateway-17
session:user:123:device:web-2 -> gateway-203
presence:user:123 -> online,last_seen=...

Identidade e Trust de Dispositivo (Core 1)

Fluxo de Registro

1. Verificação de telefone por OTP.
2. Geração local de chave de identidade.
3. Upload de pre-keys assinadas.
4. Vínculo de dispositivo a conta.

Sequência

Modelo de Dispositivo

CREATE TABLE devices (
  user_id BIGINT NOT NULL,
  device_id VARCHAR(64) NOT NULL,
  device_type VARCHAR(32) NOT NULL,
  identity_key BYTEA NOT NULL,
  signed_prekey BYTEA NOT NULL,
  status VARCHAR(16) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  revoked_at TIMESTAMP,
  PRIMARY KEY (user_id, device_id)
);

Riscos

1. SIM swap,
2. revogação lenta,
3. device velho com bundle stale.

Mitigação: alerta de segurança, revogação rápida e verificação adicional em casos de risco.

Ciclo de Vida da Mensagem (Core 2)

Envelope de Mensagem

Servidor roteia ciphertext, não plaintext.

{
  "message_id": "msg_8ab91f",
  "chat_id": "chat_772",
  "sender_user_id": "u_10",
  "sender_device_id": "ios_1",
  "recipient_scope": {
    "type": "GROUP",
    "group_id": "g_50"
  },
  "ciphertext": "base64:...",
  "encryption_meta": {
    "protocol": "signal",
    "sender_key_id": "sk_999"
  },
  "client_ts": "2026-02-22T20:10:31Z",
  "server_ts": "2026-02-22T20:10:31Z"
}

Passos de Roteamento 1:1

1. Gateway recebe envelope.
2. Router valida auth, tamanho e quota.
3. Session directory resolve devices ativos do destino.
4. Se online: entrega imediata.
5. Se offline: enqueue em fila durável.
6. Acks de estado seguem assínc.

Sequência 1:1

Estado de Entrega

• SERVER_ACCEPTED
• DEVICE_DELIVERED
• USER_READ

Semântica de Entrega e Ordenação (Core 3)

Ordenação absoluta global custa caro e não é necessária para UX de chat.

Garantias Práticas

1. ordem best-effort por conversa,
2. dedupe por id de cliente,
3. reorder buffer no cliente para atrasos pequenos.

Dedupe Key

(sender_user_id, sender_device_id, client_message_id)

Tabela de Dedupe

CREATE TABLE message_dedupe (
  sender_user_id BIGINT NOT NULL,
  sender_device_id VARCHAR(64) NOT NULL,
  client_message_id VARCHAR(64) NOT NULL,
  server_message_id VARCHAR(64) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  PRIMARY KEY (sender_user_id, sender_device_id, client_message_id)
);

Retry Sem Duplicar

Em timeout, cliente reenvia mesmo client_message_id. Servidor retorna mensagem existente caso já persistida.

Criptografia E2E com Princípios do Signal (Core 4)

Princípios

1. Servidor não lê plaintext.
2. Forward secrecy.
3. Chaves por dispositivo.
4. Trust UX coerente entre plataformas.

Tipos de Chaves

• identity key (longo prazo),
• signed pre-key,
• one-time pre-keys,
• session keys com ratchet.

Setup Conceitual de Sessão

Grupos

Pairwise puro em grupos grandes custa caro. Sistemas práticos usam otimizações estilo sender-key com políticas de rotação em mudança de membros.

Footguns

1. log excessivo de metadata sensível,
2. RNG fraco,
3. rotação tardia após comprometimento,
4. UX confusa de verificação de chave.

Arquitetura de Grupos (Core 5)

Operações

1. criar grupo,
2. adicionar/remover membros,
3. promover admins,
4. enviar mensagens com fanout.

Modelo de Grupo

CREATE TABLE groups (
  group_id VARCHAR(64) PRIMARY KEY,
  created_by BIGINT NOT NULL,
  created_at TIMESTAMP NOT NULL,
  metadata JSONB NOT NULL
);

CREATE TABLE group_members (
  group_id VARCHAR(64) NOT NULL,
  user_id BIGINT NOT NULL,
  role VARCHAR(16) NOT NULL,
  joined_at TIMESTAMP NOT NULL,
  status VARCHAR(16) NOT NULL,
  PRIMARY KEY (group_id, user_id)
);

Fanout de Grupo

Sequência Async

Membership Version

Cada mudança de grupo incrementa versão. Mensagem carrega versão para detectar contexto criptográfico stale.

Pipeline de Mídia (Core 6)

Mídia não deve atravessar router de texto.

Fluxo

1. App pede URL de upload.
2. Upload direto para object storage (blob criptografado).
3. Mensagem envia referência de mídia.
4. Destinatário baixa blob por URL assinada.
5. Decripta localmente.

Sequência

Controles

1. validar tipo real do arquivo,
2. quotas por usuário/grupo,
3. scanner para classes permitidas,
4. URLs curtas com escopo estrito.

Sincronização Multi-Dispositivo (Core 7)

Requisitos

1. convergência rápida entre devices,
2. estado lido consistente,
3. onboarding de novo device com snapshot + delta,
4. revogação imediata de device comprometido.

Snapshot + Delta

• Snapshot inicial por janela.
• Deltas realtime após checkpoint.

Sequência de Link

Regra de Conflito

Read receipts convergem por max timestamp por (chat_id, message_id, user_id).

Presence, Typing e Read Receipts (Core 8)

Presence

• efêmero,
• eventual,
• sujeito a privacy settings.

Typing

• não persistir por longo prazo,
• expirar rápido (5-10s),
• rate limit por conversa.

Read Receipts

CREATE TABLE message_receipts (
  chat_id VARCHAR(64) NOT NULL,
  message_id VARCHAR(64) NOT NULL,
  user_id BIGINT NOT NULL,
  delivered_at TIMESTAMP,
  read_at TIMESTAMP,
  PRIMARY KEY (chat_id, message_id, user_id)
);

Fluxo de Presence

Push e Entrega Offline

Pipeline

1. Router enfileira envelope para device offline.
2. Push orchestrator envia wake-up.
3. Device reconecta.
4. Device faz fetch de pendências.

Regra de Privacidade

Push não deve conter plaintext de chat E2E.

Chave de Fila

offline_queue:user:{user_id}:device:{device_id}

Sequência

Spam, Abuse e Safety

Com E2E, moderação depende muito de metadados e sinais de comportamento.

Sinais

1. velocidade de envio anômala,
2. grafo de contatos suspeito,
3. report/block rates,
4. reputação de device/IP,
5. padrões de links e anexos.

Ações

• throttle progressivo,
• limite temporário de envio,
• challenge adicional,
• suspensão em casos severos.

Exemplo de Limites

messages_per_minute por tier
new_contacts_per_day
group_creations_per_day
media_bytes_per_hour

Modelagem de Dados

Entidades

1. User
2. Device
3. Conversation
4. MessageEnvelope
5. Receipt
6. Group
7. GroupMember
8. MediaObject
9. PushToken

Envelope Table

CREATE TABLE message_envelopes (
  chat_id VARCHAR(64) NOT NULL,
  server_message_id VARCHAR(64) NOT NULL,
  sender_user_id BIGINT NOT NULL,
  sender_device_id VARCHAR(64) NOT NULL,
  ciphertext BYTEA NOT NULL,
  message_type VARCHAR(32) NOT NULL,
  server_ts TIMESTAMP NOT NULL,
  expire_at TIMESTAMP,
  PRIMARY KEY (chat_id, server_message_id)
);

CREATE INDEX idx_message_envelopes_chat_ts
  ON message_envelopes(chat_id, server_ts DESC);

Conversation Table

CREATE TABLE conversations (
  chat_id VARCHAR(64) PRIMARY KEY,
  chat_type VARCHAR(16) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  metadata JSONB NOT NULL
);

ER Simplificado

Caching e Sharding

Chaves de Particionamento

• mensagem: hash(chat_id)
• fila offline: hash(user_id, device_id)
• presence: partição por user_id
• grupo: hash(group_id)

Caches

1. Session directory cache.
2. Presence cache.
3. Group membership cache.
4. Key bundle cache.

Mitigação de Hotspots

Grupos virais podem saturar shards.

Mitigações:

1. isolamento de grupos de alto fanout,
2. autoscaling de workers por grupo,
3. rebalanceamento de partições.

Multi-Região e DR

Topologia

• regiões com gateways locais,
• ownership regional para reduzir conflito,
• replicação assíncrona para stores duráveis,
• control plane global de roteamento.

Failover

1. rotear novas conexões para região saudável,
2. preservar idempotency e dedupe,
3. degradar features não críticas (typing/presence),
4. priorizar entrega de mensagens.

Observabilidade e SLOs

SLOs

Golden Signals

Gateway:

• conexões ativas,
• churn de reconnect,
• auth failures,
• parse errors.

Router:

• route latency,
• retries,
• dedupe hit rate,
• queue publish lag.

Offline queue:

• backlog depth,
• idade de mensagem,
• expirações.

Trace IDs

x-request-id
x-chat-id
x-message-id
x-user-id
x-device-id

Dicas de Entrevista

Estrutura que pontua alto

1. Delimite 1:1, grupos, offline, mídia, multi-device.
2. Estime throughput e fanout.
3. Desenhe gateway + router + offline queue + push.
4. Explique semântica de entrega e dedupe.
5. Explique fronteiras de E2E.
6. Cubra falhas, SLOs e abuse.

Erros frequentes

1. ignorar offline queue,
2. exigir ordenação global,
3. esquecer multi-dispositivo,
4. colocar blob de mídia no caminho core,
5. omitir idempotência.

Trade-offs

Anti-Patterns

1) Tratar push como entrega garantida

Problema: push é best-effort, mensagens podem sumir da UX.

Correção: fila offline durável como fonte de verdade.

2) Mídia passando pelo router

Problema: saturação de latência e memória.

Correção: upload/download direto em object storage.

3) Sem dedupe no retry

Problema: mensagens duplicadas visíveis ao usuário.

Correção: client_message_id obrigatório + tabela dedupe.

4) Prometer ordenação absoluta

Problema: custo enorme e disponibilidade pior.

Correção: ordenação por conversa com heurísticas no cliente.

5) Ignorar hotspot de grupos

Problema: collapse de partições e workers.

Correção: isolamento e scaling por grupo quente.

6) Logar metadata sensível sem controle

Problema: risco de privacidade e compliance.

Correção: minimização, mascaramento e ACL estrita.

7) Ciclo fraco de chaves

Problema: device comprometido continua confiável.

Correção: revogação e rotação rápidas.

Conclusão

Projetar mensageria estilo WhatsApp em escala exige equilíbrio entre performance realtime e privacidade forte.

A arquitetura que funciona em produção combina:

1. conexões persistentes eficientes,
2. roteamento com fila offline robusta,
3. E2E com ciclo de chaves maduro,
4. fanout assínc para grupos,
5. fallback e observabilidade operacional.

Esse conjunto te permite responder entrevistas complexas e construir sistemas que continuam confiáveis sob carga global real.

Referências

• Signal Protocol Docs
• RFC 6455 WebSocket
• QUIC Working Group
• Apache Kafka Docs
• Google SRE Book
• OWASP Mobile Security Testing Guide
• Designing Data-Intensive Applications

Referência Rápida

Componentes Principais

Regras Críticas

1. Separar texto e mídia em paths distintos.
2. Tratar retry como normal, não exceção.
3. Modelar entrega por device, não só por usuário.
4. Isolar features não críticas do core.
5. Reduzir metadata sensível ao mínimo.

Estado de Mensagem

CLIENT_PENDING -> SERVER_ACCEPTED -> DEVICE_DELIVERED -> USER_READ

Prática de Entrevista

1. Projete grupos de 1.024 membros com picos.
2. Adicione multi-device mantendo privacidade.
3. Garanta entrega em falha regional.
4. Evite duplicação em retry storm.
5. Escale mídia sem impactar latência de texto.

Você agora tem um blueprint completo para system design de mensageria estilo WhatsApp em escala de internet.