Cómo funciona

Del payload al delivery report en menos de 500ms

Una visión profunda y honesta de cada capa de la plataforma. Nada de "magia" — solo ingeniería sólida, componentes comprobados en producción y decisiones de diseño explicables.

Arquitectura

Pipeline non-blocking de punta a punta

Cada capa fue diseñada para sostener miles de millones de mensajes/mes — con garantía de entrega, retries exponenciales en DLQ, rate-limit distribuido en Redis y observabilidad total por mensaje.

Tu Backend

App / CRM / ERP

API Gateway

REST · Webhooks · SDKs

RabbitMQ

Colas priorizadas

Workers Paralelos

Non-blocking pipeline

Meta Cloud API

WhatsApp Business

Webhooks

Callbacks · Status

Throughput

Pipeline 100% non-blocking. Colas priorizadas por tenant y tipo de mensaje.

Resiliencia

Retry exponencial, DLQ, reconciliación periódica con la Meta Cloud API.

Observabilidad

Cada mensaje rastreable end-to-end — logs, métricas, tracing y alertas.

Flujo de mensaje

8 pasos del backend a WhatsApp

Paso 01

Ingestión

POST /v1/messages llega al edge

El gateway valida schema, firma del token, deduplica por idempotency_key y enruta a la cola apropiada. 100% non-blocking — devolvemos 202 en menos de 40ms con un message_id persistido.

API GatewayJWT + scopesRedis (idempotencia)Validación OpenAPI 3.1

Paso 02

Encolado

RabbitMQ priorizada por tenant + tipo

Los mensajes van a colas separadas por prioridad (critical, high, default, low) y por tenant. Un volumen pesado de marketing nunca atrasa un OTP. Rate-limit distribuido por plantilla y por número.

RabbitMQ con lazy queuesPriorización quorum queuesRate-limit en Redis

Paso 03

Procesamiento

Workers paralelos consumiendo en loop

Cada worker toma un batch, hidrata variables de la plantilla, aplica reglas de segmentación y dispara a la Meta Cloud API. Pool auto-escalable con backpressure — no ahogamos la API downstream ni en pico.

Workers Node.jsBackpressure adaptativoPool de conexiones a Meta

Paso 04

Meta Cloud API

Entrega a WhatsApp Business

Meta devuelve un id y luego notifica el estado (queued → sent → delivered → read). En errores clasificamos en retryable / terminal y aplicamos la política adecuada.

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

Paso 05

Retry + DLQ

La falla no es fin — empieza la reconciliación

Los errores retryable van a una dead-letter queue con backoff exponencial (2s → 4s → 8s → 16s → 32s → 1min → 5min → 30min). Tras 7 intentos, el mensaje entra en reconciliación continua con Meta cada 6h por 7 días.

Dead-letter queueBackoff exponencialReconciliación cron

Paso 06

Persistencia

MongoDB como source of truth

Cada transición de estado se persiste con timestamp, metadatos de Meta, costo billable y tracing id. Índices compuestos por tenant + status + created_at permiten queries en milisegundos con miles de millones de registros.

MongoDB con shardingTTL para logsÍndices compuestos

Paso 07

Webhooks outbound

Tu backend recibe cada evento

Cada transición genera un webhook firmado con HMAC SHA-256 a tu endpoint. Redelivery automático con backoff hasta 24h, orden por message_id y replay manual desde el dashboard para los últimos 30 días.

HMAC SHA-256Redelivery workerReplay desde dashboard

Paso 08

Observabilidad

Cada mensaje rastreable end-to-end

Todo el pipeline produce logs estructurados, métricas (Prometheus) y spans de tracing (OpenTelemetry). Un único trace_id te lleva de la ingestión al webhook outbound. Dashboards Grafana públicos por tenant.

OpenTelemetryPrometheus + GrafanaLogs estructurados JSON
Pilares

Tres decisiones arquitecturales que sostienen todo

Multi-tenant nativo

Cada workspace tiene sus propias colas, rate-limits e índices MongoDB separados. Aislamiento real — no solo lógico vía WHERE tenant_id.

Seguridad en capas

Tokens con scope, rotación sin downtime, PII cifrada en reposo (AES-256) y en tránsito (TLS 1.3), audit log inmutable.

Observabilidad total

Un trace_id te lleva de la API del cliente al webhook outbound. Dashboards públicos por tenant. Sin secretos sobre lo que pasa dentro de la plataforma.

Garantías operativas

Lo que CCX te pone por escrito

Además del SLA, una lista de compromisos que entran en el contrato Enterprise y funcionan por default en el resto de los planes.

  • Idempotencia garantizada 7 días en cada endpoint
  • Cero mensajes enviados dos veces por falla interna
  • Retry en DLQ hasta 7 intentos + 7 días de reconciliación
  • Webhooks con redelivery automático de 24h y replay manual
  • SLA público con créditos financieros en caso de incumplimiento
  • Status page en tiempo real y postmortems públicos <48h
  • LGPD, GDPR, SOC 2 Type II auditables con DPA listo
  • Export completo de los datos cuando quieras (CSV, JSONL, Parquet)

¿Leíste hasta aquí? Estás listo para probar.

Activa un sandbox en 2 minutos y envía tu primera plantilla aprobada. Sin tarjeta, sin lock-in.

Cómo Funciona — Arquitectura CCX Message para WhatsApp — Reviewo