Entertainment · cinema chain · 2024 — 2025
Email notifications that don't fall over under load
An email flow split into two services connected through Azure Service Bus, so the call to SendGrid doesn't drag the rest down.
The problem
A cinema chain's platform sends an email at every step of the customer's journey: buying tickets, creating an account, recovering a password and joining the loyalty program. The flow was first designed as a single service that did everything, and under heavy load that extra work ended up taking it down.
What I did
I built that flow and proposed splitting it into two NestJS services. The first one receives the request, fetches the data and publishes a message to Azure Service Bus. The second one listens for that message and makes the call to SendGrid. That way the provider integration stays isolated from the rest of the flow.
Each email's template is picked with SendGrid dynamic templates, indexed in MongoDB: adding a new kind of email became configuration, not code. I also designed the templates.
Later, the calls to Service Bus started returning 500 errors. The cause: a new Service Bus client instance was created on every call. I fixed it by injecting the client as a dependency, so the whole service shared a single instance.
What happened
In the stress tests, the target was to handle at least 1,000 emails per minute. The flow reached 4,000.
What I took away
An industry can look quiet and still move traffic that surprises you: that's where I learned how much concurrency handling matters, and that done badly it kills services and drags the whole flow down.
NestJS · TypeScript · Azure Service Bus · SendGrid · MongoDB