tenant aísla siete marcas PPM sin levantar infraestructura
paralela. Reduce deuda técnica anticipada cuando se incorporen Pichincha Miles, BGR
o Discover Cashback al orquestador.
Propuesta arquitectónica del Orquestador de Eventos PPM como plataforma transversal multi-tenant. Venta Inteligente es el primer consumidor y el caso de prueba. Documento defendible para cierre de Discovery B.2.3 y promoción a Listo WSJF en B.2.4.
Cada decisión cierra un unknown crítico del lane CIT. Las cerradas dejan huella en el documento con fecha, contexto y puntero a la sección donde se materializan. La única abierta espera input directo del CTO.
Los actores externos publican eventos al orquestador único PPM. El orquestador alimenta a Amplitude que segmenta y enriquece; Amplitude pasa cohortes a Braze que orquesta la comunicación multicanal hacia el lead o socio.
Tres bloques de responsabilidad. El orquestador core PPM expone una sola puerta de entrada
(POST /v1/events)
y particiona el Event Hub por tenant
desde el envelope. Sin acoplamiento productor-consumidor.
tenant aísla siete marcas PPM sin levantar infraestructura
paralela. Reduce deuda técnica anticipada cuando se incorporen Pichincha Miles, BGR
o Discover Cashback al orquestador.
POST /v1/events. Envelope con
event_id, event_name, producer,
tenant, occurred_at, correlation_id,
schema_version, data. Respuesta 202 Accepted con
event_id, received_at y trace_id.
04-architecture §5 y §6.
04b §2.4 (capa
Orquestación). Braze ya contratado (cotización Minders cerrada · ver D9).
event_id, event_name, producer,
correlation_id, trace_id, status, latencia).
04-architecture §5.4) es la única fuente de verdad
sobre qué circula por el orquestador. Agnóstico de tenant: el mismo lead.captured
sirve para todas las marcas.
08-handoff.md con alcance multi-tenant completo, no solo Venta
Inteligente.
§5.4 si surgen eventos nuevos,
o las decisiones de adapter en §4.
03-sesiones-actores §1. Cobertura:
EA.4 (cloud target U1), EA.5 (IdP D4), EA.6 (compliance D3), EA.11 (naming de
eventos corporativo), EA.12 (validación de los 6 riesgos del CTO).
04-architecture §3: A) AWS-native,
B) Cloudflare-native (Workers + Queues + Durable Objects + R2), C) Híbrido
(Cloudflare frontera + AWS núcleo). Decisión depende de volumen real, latencia
tolerable, residencia EC y networking con Diners/Urbano.
06-cost-model.md no se cierra
con datos reales. Mitigado: pregunta redactada para CTO el 2026-05-21, sesión EA
cubre vía EA.4 (modelo de cuentas).
Cualquier actor publica al mismo endpoint con el mismo formato. Ocho campos meta gobiernan
ruteo, idempotencia, aislamiento multi-tenant y trazabilidad. El bloque data
viaja flat snake_case y evoluciona aditivo sin romper consumidores.
{ : "9a3b1f0e-2c4d-4e8f-b1a2-7d9c5e6f8a01", : "lead.captured", : "ram:meta-ads", : "clubmiles", : "2026-09-12T14:22:31Z", : "lead-2026-meta-78421", : "v1", "data": { "campaign_id": "meta-2026-pmax-tc-platinum", "lead_email": "maria.lopez@ejemplo.com", "lead_phone_e164": "+593998877665", "utm_source": "meta", "utm_campaign": "tc-platinum-q3" } }
Catálogo completo del v1 inicial (19 eventos · de lead.captured
a journey.completed) en 04-architecture §5.4.
El orquestador no obliga a una superficie única. Absorbe lo que las marcas ya operan hoy: REST, webhooks, FTP legacy de Diners, SDKs de vendor, CDC del core bancario. La heterogeneidad vive en la capa de adapters; el resto del orquestador solo conoce el envelope.
| Patrón | Cuándo se usa | AWS-native | Cloudflare-native |
|---|---|---|---|
| REST sync | Consultas en línea · ODV on demand, validación de scoring | API Gateway + Lambda |
Worker + fetch |
| REST async (push) | Comandos sin respuesta inmediata | API Gateway → SQS → Lambda |
Worker → Queue → consumer |
| Webhook ingest | Eventos push desde proveedores · Meta, Google, Urbano, Braze | API Gateway + Lambda + DynamoDB dedupe |
Worker + KV/D1 dedupe |
| Webhook emit | Notificar a actores externos | EventBridge → API destination |
Worker + scheduled triggers |
| FTP / SFTP batch | Diners legacy, reportes RAM | Transfer Family → S3 → EventBridge |
No nativovía AWS o agente intermedio |
| SDK | Frontends web o móvil hacia Amplitude y Braze | Vendor SDK |
Vendor SDK |
| Stream / CDC | Cambios en core Diners hacia el orquestador | DMS / Kinesis |
Externopipeline AWS hacia Cloudflare |
| Cola dedicada | Trabajos masivos · envío WhatsApp, OTP | SQS / SNS |
Queue |
| Orquestación | Journeys con estado | Step Functions |
Workflows (beta) · Durable Objects |
El orquestador no exige que los actores migren su superficie. El adapter por actor traduce al envelope §04 y publica. Los dos puntos donde Cloudflare obliga a apoyarse en AWS (FTP legacy y CDC del core) condicionan la decisión abierta U1 sobre cloud target.
Venta Inteligente paga el costo de construirlo. Las siguientes seis marcas se montan sin re-arquitectura. Sin esta decisión, el orquestador sería deuda técnica garantizada.
El C4 del CTO declara seis riesgos arquitectónicos a vigilar. Cada uno tiene una implicación directa al diseño del orquestador o a la ventana de discovery. Se documentan literalmente para anclar las decisiones futuras.
01-framing R8-R10 y elevar a comité.
06-cost-model.md futuro no se cierra hasta resolver: regularización
de créditos WhatsApp, tasa de conversión, IPs dedicadas como pago perpetuo, Currents
pago único, Content Cards sin cargos posteriores, incorporación de 6 marcas vía
adendas.
benefit.activated ya está en el catálogo, pero la lógica de
cross-sell y retención no está modelada).
Plan iterativo del lane CIT. Cada iteración entrega una salida concreta y valida una hipótesis del framing. Sin decisiones irreversibles sin spike previo.