Qué significa realmente "Gateway al 99,99 %"
Nos comprometemos a un 99,99 % de disponibilidad del gateway. Esto cubre, lo que no, cómo lo medimos y por qué es el único SLA honesto en mensajería.
La inflación de SLAs en mensajería
"Entrega del 99,999 % garantizada" aparece en una sorprendente cantidad de webs de proveedores. No puede ser cierto. Ningún proveedor controla la red del operador, el terminal del destinatario ni el entorno regulatorio que determina si un mensaje concreto llega a una persona concreta.
Lo que un proveedor *sí* puede controlar es su propio gateway: la API, el motor de enrutamiento, las conexiones con vendors, la monitorización. Ahí es donde vive el compromiso del 99,99 % de Flowstates, y conviene explicar qué entra y qué queda fuera.
Qué entra en el alcance
Nuestro 99,99 % de disponibilidad del gateway cubre:
- Ingestión por API: cada solicitud API se acepta y se encola
- Decisiones de enrutamiento: cada mensaje se despacha por una ruta de vendor
- Salud de la conexión con vendors: mantenemos conexiones calientes con tus vendors
- Procesamiento de DLR: las actualizaciones de estado de los vendors se reciben y reenvían
- Entrega de webhooks: los callbacks de estado llegan a tu aplicación
Medido: porcentaje de solicitudes API aceptadas y enrutadas con éxito en un mes. Excluido: ventanas de mantenimiento planificado anunciadas con 7+ días de antelación.
Un 99,99 % al mes equivale a ~4 minutos 20 segundos de inactividad no planificada.
Qué queda fuera del alcance
Respuesta honesta: muchas cosas.
- Caídas de la red del operador. Si un MNO importante tiene un incidente SS7, los mensajes a ese operador no se entregarán, independientemente de la disponibilidad del gateway.
- Caídas de vendors en rutas que tú controlas. Si tu vendor SMPP principal cae y no has configurado un fallback, el gateway está arriba pero tus mensajes no llegan.
- Decisiones de filtrado de los carriers. Los filtros de spam de los operadores pueden descartar o retrasar tráfico sin previo aviso. Detectarlo y reenrutar forma parte de operaciones, no del SLA.
- Estado del terminal destinatario. Apagado, sin cobertura, remitente bloqueado: ninguno de estos es un problema del gateway.
- Cambios impulsados por reguladores. Nuevas reglas 10DLC, re-registros de sender ID, re-aprobación de plantillas: generan impacto aguas abajo que el SLA no cubre.
Por eso "entrega garantizada" no significa nada. Ningún SLA de vendor puede cubrir creíblemente las partes del sistema que el vendor no opera.
Cómo lo medimos
Tres dimensiones:
- Transacciones sintéticas cada 30 segundos contra la API y contra rutas de prueba a través de cada vendor conectado. Se ejecutan desde múltiples orígenes geográficos.
- Telemetría de producción del gateway de API y de la capa de enrutamiento, agregada por minuto y conservada 13 meses para reporting de SLA.
- Salud de la conexión con vendors monitorizada de forma continua: si alguna ruta conectada se degrada, lo detectamos, enrutamos alrededor cuando es posible y registramos el evento.
El número de disponibilidad mensual se calcula a partir de la telemetría de producción, no de los sintéticos. Los sintéticos son un sistema de aviso temprano, no la medida oficial.
Qué obtienes si no llegamos
El remedio estándar por incumplir el SLA del gateway son créditos de servicio, aplicados como porcentaje de la cuota de gateway del mes. No del coste por mensaje del vendor (que nosotros no cobramos). Las condiciones específicas están en tu acuerdo de cliente.
Más importante: cada incidente relevante para el SLA recibe un postmortem escrito en un plazo de 5 días hábiles, hayamos incumplido el umbral o no.
Dónde encaja la capa operativa
La razón por la que somos conservadores con lo que cubre el SLA es que el valor de trabajar con un gateway gestionado está mayormente fuera del propio gateway. Es:
- Monitorización continua de rutas que tu equipo no tiene tiempo de vigilar
- Escalados a vendors durante incidentes en el lado del operador
- Cambios de enrutamiento cuando el filtrado de carrier se mueve
- Gestión de cumplimiento y registros conforme cambian las reglas por mercado
Esto no cabe en un único número de uptime. Aparece en tus tasas de conversión, en la frecuencia de tus incidentes y en la ausencia de avisos a las 3 de la mañana que tu equipo no ha tenido que atender.
Qué preguntar a cualquier proveedor de mensajería
Tres preguntas que conviene hacer al evaluar un gateway o proveedor CPaaS:
- ¿Qué cubre realmente vuestro SLA, en términos técnicos: solo API, o entrega extremo a extremo?
- ¿Cómo se mide y puedo ver la telemetría subyacente?
- ¿Cuál es el tiempo de respuesta a incidentes publicado para una degradación de ruta que está *fuera* del SLA?
La tercera pregunta suele ser la más reveladora. Los vendors que hacen esto bien tienen una respuesta preparada. Los que tratan operaciones como problema del cliente, no.
Si quieres ver cómo reportamos contra el SLA, o hablar de cómo sería un SLO operativo cubriendo tus mercados específicos, reserva una revisión de mensajería de 30 minutos.