A high-availability SMS banking service under critical traffic

Problem

SINPE is Costa Rica’s SMS-based system for banking transactions — a message isn’t just a notification, it’s the confirmation channel for a real transfer. That changes the engineering bar: the service has to survive high request volume during peak banking hours, guarantee that no message is silently dropped, and just as importantly guarantee that no message is processed twice, since a duplicate delivery in a banking context can mean a duplicate transaction attempt.

Solution

As part of the team, I worked on the queueing and delivery layer behind the service: Redis + BullMQ queues to absorb traffic spikes without blocking the request path, delivery-status webhooks so the system always knows whether a message actually reached its destination, and automatic retries paired with idempotency keys across queries, users, and API interactions — so a retried operation can never be double-counted. Error monitoring sat on top of the whole pipeline so a failure surfaced immediately instead of silently disappearing into a queue.

Impact

• The service ran in production processing high-volume banking-SMS traffic without message loss or duplication under critical load.
• The idempotency + retry pattern built here became a template reused across other high-volume messaging integrations (WhatsApp Business API, SendGrid) on the same platform.
• Reinforced a principle that shaped later architecture decisions: in a messaging system, “delivered” and “delivered exactly once” are different guarantees, and the second one is the one that actually matters when money is involved.