Components

Platform Components

The SMS Gateway Proxy platform consists of application services that handle business logic and infrastructure services that provide storage, caching, and monitoring capabilities. All components run as Docker containers and communicate over internal networks.

Application Services

Authentication Service

The authentication service manages user identities, access control, and authorization. It provides the security layer that protects all messaging operations.

• User registration — create new accounts with email and password credentials. Each user is assigned a unique app_id and app_secret for API access.
• Token-based authorization — users authenticate via login and receive a JWT token. The token must be included in all subsequent API requests (both REST and gRPC).
• Admin privileges — designated admin users have access to platform management endpoints: SMPP link control, user management, configuration, and system statistics.
• Admin Key authentication — administrative endpoints additionally support static Admin Key authentication for system-level operations and automation.

SMS Service

The SMS service provides messaging capabilities over the SMPP infrastructure, allowing authorized clients to send and track SMS messages.

• Single message sending — submit an SMS with source address, destination, text, and target ESME/pool. The service handles validation, encoding detection, segmentation, and routing.
• Bidirectional streaming — maintain a persistent gRPC connection for high-throughput message submission. Each request produces a corresponding response with delivery status.
• ESME connection monitoring — check the availability and state of SMPP links in real time via the CheckESME method.
• Message encoding analysis — the CheckTextLen method detects encoding (GSM7, Latin-1, UCS-2), counts characters, and calculates the number of SMS segments required.
• Delivery tracking — query the status of previously sent messages, including per-segment delivery information via SmsInfo.
• Contact policy enforcement — before submission, each message passes through the Message Control Platform (MCP) for contact policy validation (frequency limits, deduplication, blacklist checks).

Message Control Platform (MCP)

The MCP is a visual filtering engine built on Node-RED that enforces contact policies before messages reach the SMPP infrastructure.

• Strategy-based filtering — configurable strategies (CP1, CP2, Blacklist, Health Check) determine whether a message is allowed or rejected.
• Frequency limiting — daily and weekly contact limits per destination number.
• Deduplication — prevents duplicate messages within a configurable time window.
• Blacklist management — maintains phone number blacklists loaded from S3/MinIO storage.
• Horizontally scalable — multiple Node-RED instances share the same flows and Redis backend.

For detailed MCP documentation, see Message Control Platform.

Infrastructure Services

Redis

Redis serves two critical functions in the platform:

• Distributed L2 rate limiting — enforces per-link and per-pool message rate limits across all proxy instances. Rate limits are dynamically adjusted when SMPP links go up or down.
• MCP state storage — stores contact policy counters, deduplication keys, and blacklist entries used by the Message Control Platform.

Aerospike

Aerospike is the persistent datastore for message lifecycle tracking.

• Stores message submission records (message ID, transaction ID, destination, timestamp, routing info)
• Tracks delivery status updates from SMPP delivery receipts (DLR)
• Provides fast key-value lookups for real-time delivery status queries
• Used for operational message state only — not for long-term archival storage

S3 / MinIO

S3-compatible object storage is used for:

• Journal export — message activity logs and statistics are periodically exported to S3 for auditing and offline analysis.
• Blacklist storage — CSV files containing blacklisted phone numbers are stored in S3 and loaded into Redis by the MCP.

Component Interaction Summary