Un servicio bancario de SMS de alta disponibilidad bajo tráfico crítico

Problema

SINPE es el sistema costarricense de transacciones bancarias vía SMS — un mensaje no es solo una notificación, es el canal de confirmación de una transferencia real. Eso cambia la exigencia de ingeniería: el servicio tiene que sobrevivir a un alto volumen de solicitudes en horas pico bancarias, garantizar que ningún mensaje se pierda silenciosamente y, con la misma importancia, garantizar que ningún mensaje se procese dos veces, porque una entrega duplicada en un contexto bancario puede significar un intento de transacción duplicado.

Solución

Como parte del equipo, trabajé en la capa de colas y entrega detrás del servicio: colas de Redis + BullMQ para absorber picos de tráfico sin bloquear el camino de la solicitud, webhooks de estado de entrega para que el sistema siempre sepa si un mensaje realmente llegó a su destino, y reintentos automáticos combinados con claves de idempotencia en consultas, usuarios e interacciones de API — de forma que una operación reintentada nunca pueda contarse dos veces. El monitoreo de errores cubría todo el pipeline para que una falla apareciera de inmediato en vez de desaparecer silenciosamente dentro de una cola.

Impacto

• El servicio corrió en producción procesando tráfico bancario de SMS de alto volumen sin pérdida ni duplicación de mensajes bajo carga crítica.
• El patrón de idempotencia + reintentos construido aquí se convirtió en una plantilla reutilizada en otras integraciones de mensajería de alto volumen (WhatsApp Business API, SendGrid) en la misma plataforma.
• Reforzó un principio que marcó decisiones de arquitectura posteriores: en un sistema de mensajería, “entregado” y “entregado exactamente una vez” son garantías distintas, y la segunda es la que realmente importa cuando hay dinero de por medio.