Case Study

Doer SMS Service — Enterprise Messaging

Team Lead & Full Stack Developer · Doer Services PLC

  • Spring Boot
  • RabbitMQ
  • Angular
  • Java 17
  • REST API
  • Linux

Overview

A resilient, high-volume enterprise messaging gateway capable of processing millions of SMS notifications, transactional alerts, and two-factor authentication (2FA) OTPs per day. The platform features an intelligent multi-operator routing engine, failover handling between telecom aggregators, queue prioritization, and detailed delivery status reporting (DLR).

Problem

Businesses needed to send notifications, alerts and one-time passwords at volume, through several telecom operators, without a single aggregator having a bad hour that silently swallows the messages people are waiting on to log in.

My role

Team lead and full stack developer — led messaging pipeline implementation, database sanity testing, and production server management.

Architecture

Spring Boot messaging API backed by RabbitMQ message queues for asynchronous delivery, PostgreSQL/MySQL storage, and an Angular administrative dashboard.

Enterprise SMS dispatch, routing and delivery reporting flow Client applications and an Angular dashboard call a Spring Boot messaging API, which enqueues messages to RabbitMQ on priority queues so time-critical one-time passwords are not held behind bulk campaigns. Dispatch workers route to telecom aggregators with failover between them, and delivery receipts are reconciled back into the message store. Client Applications API callers Angular Dashboard Spring Boot Messaging API Priority Queue OTP & transactional Bulk Queue campaigns Dispatch & Routing Worker Operator A aggregator PostgreSQL / MySQL Operator B failover first DLR
Solid lines carry a request and wait for a reply. Dashed lines hand work off and do not.

Key challenge

Not every message is equally urgent, and the queue does not know that on its own. A one-time password is worthless if it arrives after the user gives up, so it cannot sit behind a bulk campaign of hundreds of thousands — which makes prioritisation and per-operator routing part of the pipeline rather than a setting. Delivery receipts then come back from the carriers out of order and late, and have to be reconciled against what was sent.

Result

Transactional alerts and OTPs are dispatched at volume across multiple operators with failover between aggregators, queue priority keeping the time-critical traffic ahead of bulk, and delivery status reported per message.