Entretenimiento · cadena de cines · 2024 — 2025
Notificaciones por email que no se caen con la carga
Un flujo de correo partido en dos servicios conectados por Azure Service Bus, para que la llamada a SendGrid no arrastre al resto.
El problema
La plataforma de una cadena de cines envía un correo en cada paso del cliente: la compra de entradas, la creación de cuenta, la recuperación de contraseña y la suscripción al programa de fidelización. El flujo se diseñó al principio como un solo servicio que hacía todo, y con mucha carga ese trabajo extra lo terminaba tumbando.
Lo que hice
Construí ese flujo y propuse separarlo en dos servicios en NestJS. El primero recibe la solicitud, busca los datos y publica un mensaje en Azure Service Bus. El segundo escucha ese mensaje y hace la llamada a SendGrid. Así la integración con el proveedor queda aislada del resto del flujo.
La plantilla de cada correo se elige con las dynamic templates de SendGrid, indexadas en MongoDB: sumar un tipo de correo nuevo pasó a ser configuración, no código. También diseñé las plantillas.
Después aparecieron errores 500 en las llamadas a Service Bus. La causa: se creaba una instancia nueva del cliente de Service Bus en cada llamada. Lo corregí inyectándolo como dependencia, para que todo el servicio compartiera una sola instancia.
Qué pasó
En las pruebas de estrés, la meta era soportar al menos 1.000 correos por minuto. El flujo llegó a 4.000.
Lo que me llevé
Una industria puede verse tranquila y mover un tráfico que sorprende: ahí aprendí cuánto pesa el manejo de la concurrencia, y que mal resuelto mata servicios y arrastra el flujo completo.
NestJS · TypeScript · Azure Service Bus · SendGrid · MongoDB