Load Balancing

Virtual SMPP Pools & Weighted Load Balancing

This project supports virtual SMPP pools that allow grouping multiple physical SMPP links into a single logical sender with weighted load balancing.

From the perspective of the upper layers, a pool behaves exactly like a regular SMPP client, while internally it distributes traffic across multiple underlying SMPP links.

Virtual SMPP Pools & Weighted Load Balancing

The platform supports virtual SMPP pools, allowing multiple physical SMPP connections to be grouped into a single logical sender.
This mechanism enables weighted load balancing, improved fault tolerance, and flexible routing strategies without requiring changes in application logic.

From the perspective of higher-level services, a pool behaves exactly like a standard SMPP client. Internally, however, it distributes traffic across multiple physical SMPP links according to configured weights.

Core Concept

• Physical links (link 100, link 101, link 102, link 103) represent actual SMPP connections to SMSCs.
• Virtual pools (pool 1000, pool 1001) are logical senders composed of several physical links.
• Each pool applies weighted load balancing to distribute traffic among its member links.
• Both single links and pools implement the same SMPPclient interface, making them fully interchangeable.

This design allows routing strategies to evolve through configuration rather than code changes.

Architecture Overview

Common Links Registry

All physical SMPP links are created and registered once during system initialization.

• Each link maintains its own connection state
• Each link enforces its own rate limits
• Each link tracks its own health status

This ensures that all pools reuse the same physical connections.

Virtual Pools

A pool is defined as a logical sender composed of multiple physical links.

• Pools reference links by their ESME IDs
• Each member link is assigned a weight representing its share of traffic
• Pools do not create new SMPP connections — they reuse existing ones

This approach avoids duplication of connections and simplifies operational management.

Load Balancer (LB)

Each pool contains an internal load balancer responsible for selecting the target link for each message.

• Link selection is based on configured weights
• The algorithm uses Smooth Weighted Round-Robin
• Selection is stateful and thread-safe

This ensures stable and predictable traffic distribution.

Unified Sender Interface

From the perspective of the upper layers, both physical links and virtual pools expose the same sending interface.

Submit Single Message
Submit Long Message
Submit in Payload Message

Because of this unified interface, a single link can be replaced with a pool without modifying application code.

Example Pool Configuration

[pools.1000]
100 = 1000
101 = 1000
102 = 800

[pools.1001]
103 = 1000

Pool 1000

• Uses links 100, 101, 102

• Traffic is distributed according to configured weights

Pool 1001

• Uses link 103 only

• Behaves effectively as a single-link sender

Message Flow

1. A client sends a message to a pool (for example pool 1000).

2. The pool’s load balancer selects one of its member links based on configured weights.

3. The message is forwarded to the selected physical SMPP client.

4. The physical client sends the message to the SMSC.

5. Delivery tracking and message lifecycle remain transparent to the caller.

Key Benefits

• Traffic distribution across multiple SMPP connections

• High availability through link redundancy

• Zero duplication of SMPP connections

• Configuration-driven behavior without code changes

• Transparent integration with existing routing logic

• Thread-safe and production-ready design

Design Principles

• Pools use composition rather than inheritance

• Load balancing logic is decoupled from SMPP protocol handling

• Connection health and state are owned by individual links

• Upper layers do not distinguish between a link and a pool