Tráfico transaccional vs marketing en el mismo gateway

El problema de la ruta compartida

Cuando el tráfico es pequeño, es tentador enviar todo por la misma ruta de vendor. Una integración, un set de credenciales, una factura.

Esto funciona hasta que la primera ráfaga de marketing colisiona con el pico de tráfico de OTP. Entonces:

• La latencia transaccional se dispara de menos de un segundo a 20–60 segundos
• Algunos OTP llegan después de que la ventana TOTP se haya cerrado
• La conversión en el flujo de login cae 5–15 %
• Se culpa al equipo de marketing; nadie puede demostrar qué pasó realmente

La causa raíz es casi siempre enrutamiento compartido entre clases de tráfico con características muy distintas.

Por qué ambas clases no se mezclan

Tráfico transaccional (OTPs, resets de contraseña, alertas):

• Sensible a latencia (debe llegar en menos de 10 segundos)
• Bursty (picos de login, picos por hora del día)
• Volumen absoluto bajo por usuario pero alto impacto reputacional por fallo
• Contenido amigable para regulador y operador

Tráfico de marketing (promociones, win-backs, anuncios):

• Tolerante a latencia (entrega en minutos vale)
• Predecible (las campañas se programan)
• Volumen absoluto alto
• Sujeto a escrutinio de opt-in, filtrado de contenido y restricciones por hora del día

Carriers y aggregators aplican throttling a nivel de ruta. Una ráfaga de marketing de 200.000 mensajes no solo se ralentiza a sí misma: ralentiza todo lo que comparte esa ruta.

Cómo separar correctamente

Hay tres capas que hay que acertar.

1. Sender IDs separados

Usa sender IDs (o short codes) distintos para transaccional vs marketing. Los operadores aplican reglas de filtrado distintas por sender ID. Compartir un sender ID entre ambas clases significa o bien:

• El sender transaccional queda marcado por contenido de marketing, o
• El sender de marketing recibe trato más limpio gracias a la reputación transaccional, y la pierde tras la primera revisión de contenido

En EE. UU. bajo 10DLC, el registro también difiere: el caso de uso declarado afecta al tier de throughput y a la postura de filtrado.

2. Rutas separadas (e idealmente vendors)

Incluso con el mismo vendor, pide IDs de ruta separados para las dos clases de tráfico. Mejor aún, enrútalas por vendors completamente distintos. Esto te da:

• Asignaciones independientes de throughput
• Dominios de fallo independientes
• Comportamiento de throttling independiente
• Contratos y SLAs independientes

La mayoría de gateways gestionados te dejan expresar esto como una regla de enrutamiento: clase de tráfico → ruta → ruta de fallback.

3. Umbrales de monitorización separados

Una vez separadas las rutas, monitorízalas de forma distinta:

• Transaccional: alerta si p95 de latencia supera 10 s, o si la conversión cae más de 3 % en 5 minutos
• Marketing: alerta si la tasa de DLR baja del 95 %, errores de throttling de vendor, tasas de marca-spam

Disparar una alerta a las 3 de la mañana por una campaña de marketing que se entregó lenta es ruido. Disparar una por un aumento de latencia de OTP de 4 segundos no lo es.

El modelo operativo

En producción, la regla de enrutamiento se ve así:

if traffic_class == "otp":
    primary = vendor_a / route_otp_priority
    fallback = vendor_b / route_otp_secondary
elif traffic_class == "transactional":
    primary = vendor_a / route_txn
    fallback = vendor_b / route_txn
elif traffic_class == "marketing":
    primary = vendor_c / route_marketing_bulk
    fallback = vendor_a / route_marketing

Las restricciones clave:

• Marketing nunca hace fallback a rutas de OTP
• El fallback de OTP es un vendor con una ruta caliente, no un standby frío
• La optimización de coste solo aplica al tráfico de marketing; OTP se optimiza por latencia

Dónde sí está bien compartir infraestructura

La capa de aplicación puede compartir infraestructura entre clases sin problema: misma API, mismo stack de observabilidad, mismo equipo de soporte. La separación tiene que ocurrir en:

• Sender ID
• Ruta de vendor
• Asignación de throughput
• Umbrales de alerta

Lo demás puede unificarse.

Errores comunes que vemos

Cuando onboardeamos a un cliente con un perfil de entrega degradado, el diagnóstico casi siempre encuentra uno de estos:

1. Un único sender ID usado para OTP y marketing porque "era más fácil"
2. Campañas de marketing programadas durante las horas pico de OTP
3. Una ruta compartida que toca techos de throttling durante ráfagas de marketing
4. Sin diferenciación de alertas, así que el equipo de guardia se desensibiliza al ruido relacionado con marketing

Los cuatro son corregibles en días, no semanas.

---

Si tus números de entrega se sienten inconsistentes y sospechas que la colisión entre clases de tráfico es la causa, reserva una revisión de mensajería de 30 minutos. Miramos tu setup de enrutamiento y te decimos qué arreglar primero.