Como funciona

Do payload ao delivery report em menos de 500ms

Uma visão profunda e honesta de cada camada da plataforma. Nada de "mágica" — só engenharia sólida, componentes comprovados em produção e decisões de design explicáveis.

Arquitetura

Pipeline non-blocking de ponta a ponta

Cada camada foi projetada para sustentar bilhões de mensagens/mês — com garantia de entrega, retries exponenciais em DLQ, rate-limit distribuído em Redis e observabilidade total por mensagem.

Seu Backend

App / CRM / ERP

API Gateway

REST · Webhooks · SDKs

RabbitMQ

Filas priorizadas

Workers Paralelos

Non-blocking pipeline

Meta Cloud API

WhatsApp Business

Webhooks

Callbacks · Status

Throughput

Pipeline 100% non-blocking. Filas priorizadas por tenant e tipo de mensagem.

Resiliência

Retry exponencial, DLQ, reconciliação periódica com a Meta Cloud API.

Observabilidade

Cada mensagem rastreável end-to-end — logs, métricas, tracing e alertas.

Fluxo de mensagem

8 passos do backend ao WhatsApp

Passo 01

Ingestão

POST /v1/messages chega na borda

O gateway faz validação de schema, assinatura do token, dedup por idempotency_key e encaminha para a fila apropriada. 100% non-blocking — retornamos 202 em menos de 40ms com um message_id persistido.

API GatewayJWT + scopesRedis (idempotência)Validação OpenAPI 3.1

Passo 02

Enfileiramento

RabbitMQ priorizada por tenant + tipo

Mensagens vão para filas separadas por prioridade (critical, high, default, low) e por tenant. Isso garante que um volume pesado de marketing nunca atrase um OTP. Rate-limit distribuído por template e por número.

RabbitMQ com lazy queuesPriorização quorum queuesRate-limit em Redis

Passo 03

Processamento

Workers paralelos consumindo em loop

Cada worker pega um batch, hidrata variáveis do template, aplica regras de segmentação e dispara para a Meta Cloud API. Pool auto-escalável com backpressure — não sufocamos a API downstream mesmo em pico.

Workers Node.jsBackpressure adaptativoConnection pool com Meta

Passo 04

Meta Cloud API

Entrega ao WhatsApp Business

A Meta retorna um id e, em seguida, notifica status (queued → sent → delivered → read). Em caso de erro, classificamos em retryable / terminal e tratamos com política apropriada.

Meta Graph API v19+Timeout agressivo (2s)Circuit breaker por número

Passo 05

Retry + DLQ

Falha não é fim — é começo de reconciliação

Erros retryable vão para uma dead-letter queue com backoff exponencial (2s → 4s → 8s → 16s → 32s → 1min → 5min → 30min). Após 7 tentativas, a mensagem entra em reconciliação contínua com a Meta a cada 6h por 7 dias.

Dead-letter queueBackoff exponencialReconciliação cron

Passo 06

Persistência

MongoDB como source of truth

Cada transição de estado é persistida com timestamp, metadados da Meta, custo billable e tracing id. Índices compostos por tenant + status + created_at permitem queries em milissegundos mesmo com bilhões de registros.

MongoDB com shardingTTL para logsÍndices compostos

Passo 07

Webhooks outbound

Seu backend recebe cada evento

Cada transição gera um webhook assinado por HMAC SHA-256 para seu endpoint. Redelivery automático com backoff até 24h, ordenação por message_id, e replay manual via dashboard para os últimos 30 dias.

HMAC SHA-256Redelivery workerReplay dashboard

Passo 08

Observabilidade

Cada mensagem rastreável end-to-end

Todo o pipeline produz logs estruturados, métricas (Prometheus) e spans de tracing (OpenTelemetry). Um único trace_id te leva da ingestão ao webhook outbound. Dashboards Grafana públicos por tenant.

OpenTelemetryPrometheus + GrafanaLogs estruturados JSON
Pilares

Três decisões arquiteturais que sustentam tudo

Multi-tenant nativo

Cada workspace tem filas próprias, rate-limits próprios e índices MongoDB separados. Isolamento real — não lógico via WHERE tenant_id.

Segurança em camadas

Tokens com escopo, rotação sem downtime, PII criptografada em repouso (AES-256) e em trânsito (TLS 1.3), audit log imutável.

Observabilidade total

Um trace_id te leva da API do cliente até o webhook outbound. Dashboards públicos por tenant. Sem segredo sobre o que acontece dentro da plataforma.

Garantias operacionais

O que a CCX te dá por escrito

Além do SLA, uma lista de compromissos que entram no contrato Enterprise e funcionam por default nos outros planos.

  • Idempotência garantida por 7 dias em cada endpoint
  • Nenhuma mensagem enviada duas vezes por falha interna
  • Retry em DLQ até 7 tentativas + 7 dias de reconciliação
  • Webhooks com redelivery automático de 24h e replay manual
  • SLA público com créditos financeiros em caso de descumprimento
  • Status page em tempo real e postmortems públicos <48h
  • LGPD, GDPR, SOC 2 Type II auditáveis com DPA pronto
  • Export completo dos dados em qualquer momento (CSV, JSONL, Parquet)

Leu até aqui? Está pronto para testar.

Ative um sandbox em 2 minutos e envie seu primeiro template aprovado. Sem cartão. Sem fidelidade.

Como Funciona — Arquitetura da CCX Message para WhatsApp — Reviewo