What building an SMPP server taught me about reliability

From July to August 2024 I was an intern at MISTA LLC. It was my first close look at how businesses communicate at scale: SMS gateways, the SMPP protocol and the other channels companies use to reach customers.

In September 2024 I started with Trust SMS Uganda as Infrastructure Manager, responsible for their SMS gateway infrastructure, which connects through different international telecom operators.

What SMPP is

SMPP (Short Message Peer-to-Peer) is the protocol most of the SMS industry uses to exchange messages between applications, aggregators and mobile operators.

Unlike a simple web API, SMPP keeps long-lived connections open, sends messages as binary packets, and expects both sides to acknowledge everything. Delivery reports come back on their own schedule. If a connection drops, messages can be delayed or lost unless the system is built to handle it.

Building a custom server

For Trust SMS Uganda I built a custom SMPP server. It started in Python. Later I added Node.js, for better performance and for raw, low-level access to the SMPP protocol itself rather than working through layers of abstraction.

I can't describe the client's internal setup, but the lessons are general.

The lessons

Connections fail, so plan for it. Long-lived connections will drop. Reconnection and resending have to be designed in from the start.

Track the state of every message. Each message needs a clear state: submitted, accepted, delivered or failed. Without it, you can't answer the first question every customer asks: did my message arrive?

Several operators means several behaviours. Connecting through different international telcos means the system has to cope with each one's differences.

Control matters at the protocol level. Moving to raw SMPP access in Node.js gave me control that higher-level tools hid, and better performance with it.

Where it led

In January 2026 I built and put into production custom VoIP software and two-way SMPP software for Trust SMS Uganda, so messages and calls could flow in both directions.

What I took from it

Reliability is a design decision, not a feature you add later.

Choose the language for the job. Python was the right start. Node.js was the right next step when performance and protocol control mattered more.

Infrastructure work is invisible when it's done well. Nobody notices a message that arrives. Everyone notices one that doesn't.