SMS Gateway Scalability: Throughput, Queues and Capacity

"We need to scale our SMS" almost always turns out to mean one of three different problems: the application cannot submit fast enough, the gateway is throttling submissions, or the destination side will not accept traffic any faster. They have different fixes, and adding application servers only helps with the first.

Find the rate that binds first

There are at least three distinct rates in any sending path, and the slowest one sets your real throughput.

• Application submission rate: how fast your own code can create and submit messages, including database writes, template rendering and connection handling.
• Gateway acceptance rate: how fast submissions are accepted on your connection, which depends on the agreed configuration rather than on how many application instances you run.
• Destination-side rate: what the onward route, destination network and your sender arrangement will accept, which is usually the hardest limit to change quickly.

Downstream limits do not disappear because your platform scaled out. Public provider documentation makes this concrete: Twilio's error 30001 describes messages queueing because of sending rate and sender-level limits, which is a provider-specific example of a general truth — messages wait somewhere, and where they wait determines what you can do about it. For MessageTrade services, connection method, endpoint, throughput and enabled functions are agreed during solution design rather than being a fixed published number, so peak planning starts by discussing expected volumes with the MessageTrade team through our carrier and SMS aggregator gateway service.

Count segments, not messages

Downstream SMS traffic commonly consumes capacity per segment rather than per API call, but an integration may also enforce limits on requests per second, on messages in flight or window size, or per account and sender. Check the agreed units at each stage, because the billable unit does not automatically equal every rate limit. A message that exceeds the single-segment limit for its encoding is split, and each part consumes capacity and cost. Typical GSM-7 figures are 160 septets for a single segment and 153 per part when concatenated; UCS-2 typically allows 70 code units, or 67 per part. Some extended-alphabet characters and emoji consume more than one unit, and route or header conventions can change the arithmetic, so treat these as usual cases rather than universal counts — public segmentation documentation sets out the mechanics, but the applicable units for your traffic should be confirmed for your service and price structure.

The practical consequence: a campaign of 8,000 long Unicode messages can easily represent three or four times the capacity of 8,000 short GSM-7 messages. Plan peaks in segments.

Queue age matters more than queue depth

Depth on its own says little. A large queue that drains quickly can be perfectly healthy, while a small queue holding items that have waited minutes can be an incident for authentication traffic. There is no universal healthy threshold: it depends on how long the message stays valid and useful for the use case, and on the service objectives you have agreed. Monitor the age of the oldest queued item alongside depth, and alert on age against a threshold chosen for that traffic class.

This is the tail-versus-average problem again. As the SRE monitoring guidance argues, saturation and latency percentiles reveal problems that mean values conceal. A mean queue wait of two seconds is compatible with a badly broken authentication experience for the slowest few per cent of users.

A worked backlog example

Illustrative arithmetic makes the shape of a peak visible. Suppose 6,000 single-segment messages are submitted at once, and the path accepts a constant 100 segments per second. With no new arrivals and no overhead, the backlog needs at least 60 seconds to drain, and the last message in the queue waits roughly that long. Double the average message to two segments and the same submission becomes 12,000 segments and at least 120 seconds.

This is deliberately simplified illustrative arithmetic, not a MessageTrade capacity figure and not a promise of any specific rate. Its value is that it forces a design question: is a minute of queueing acceptable for this traffic class, and if not, does the answer lie in a higher agreed rate, in spreading the submission, or in sending fewer segments?

Separate sustainable capacity from burst capacity

Write down two numbers for each traffic class: the rate you expect to sustain for long periods, and the burst you expect occasionally. Then decide what happens when the burst exceeds the sustainable rate. Options include prioritising authentication and transactional traffic ahead of promotional traffic, shaping bulk sends across a longer window, setting a validity period so that stale messages expire rather than arriving uselessly late, and deferring non-urgent traffic out of the peak.

Also plan recovery capacity. If one route is unavailable and traffic concentrates onto the remainder, the surviving capacity is lower and the backlog from the outage still has to drain on top of live traffic. Whether rerouting is available at all depends on the agreed service, the configured conditions and route availability, and it can affect costs.

Test the load you actually plan to send

• Agree the test in advance with your provider, including window, destinations, volumes and how it will be stopped.
• Use realistic message sizes and encodings, because segment counts change the result.
• Test the peak shape, not just the total: a spike at the top of the hour behaves differently from a smooth ramp.
• Watch queue age, acceptance rate, rejection codes and receipt latency together, not delivery percentage alone.
• Record the baseline so the next test has something to compare against.

Scalability work pays off when it produces a number you trust for each traffic class and a documented behaviour for the moment that number is exceeded. Everything else is guesswork with more servers attached.