SMS throughput planning: TPS, queues and priority traffic

SMS capacity should be planned in segments per second, not messages alone. The workload is then split into service classes: OTP, transactional notifications and bulk campaigns receive separate queues, limits and delivery objectives. This prevents a large campaign from consuming the whole route and delaying an authentication code.

Start with the traffic profile

Monthly message volume says little about a peak. Capacity planning needs:

• normal and maximum event-creation rates;
• peak duration and possible backlog;
• the share of OTP, service and marketing traffic;
• the distribution of message length and encoding;
• countries, operators, sender IDs and routes;
• acceptable queue time for every class;
• retry and fallback policy;
• expected growth over at least one capacity cycle.

A peak does not only come from customers. When a dependent system recovers, accumulated jobs may be released at once. This recovery burst is often more severe than the normal daily maximum.

Messages and segments are different units

An SMS beyond the permitted payload is split into parts. Characters outside GSM-7 reduce the capacity of one segment, while concatenated messages reserve header space for assembly. One user notification can therefore consume two, three or more transmitted segments.

Use this starting estimate:

segments_per_second = messages_per_second × average_segments_per_message

The average is not enough. Calculate the P95 segment count and the share of the longest templates. Inspect the final body after substituting a name, amount and URL: dynamic fields often push a message over the next segment boundary.

Estimating queue drain time

If the backlog contains Q segments and sustainable useful capacity is C, the minimum drain time is approximately Q / C. In production, reserve capacity for route variation, retries, protocol overhead and uneven distribution between mobile networks.

A backlog of 180,000 segments at a sustainable 1,000 segments per second needs at least three minutes to drain. That is unacceptable for an OTP even if average daily capacity appears sufficient.

Design around the target wait time. If OTP must leave your system within two seconds, its queue and reserved quota must absorb that peak independently of a marketing campaign.

Isolate service classes

One FIFO queue is simple but creates head-of-line blocking: thousands of low-priority messages can sit ahead of an urgent code. A reliable design uses separate queues and a scheduler:

• OTP — short TTL, the highest burst quota and strict protection against duplicate issuance;
• transactional — order, appointment and payment events with their own SLO;
• bulk — controlled rate, a sending window and a safe campaign stop;
• retries — a separate budget so that an outage cannot double the primary stream.

Priority does not mean unlimited throughput. Give every class a maximum quota and prevent one customer or workflow from producing anomalous load.

Limits exist at several layers

Overall platform capacity does not guarantee the same rate for one destination. Limits may apply to:

• an API key or SMPP session;
• a customer or sender ID;
• country, operator or route;
• traffic type or template;
• concurrent sessions and outstanding requests;
• a campaign’s permitted sending window.

QuickTel publishes a platform capacity of up to 8,000 SMS per second, but an individual project’s observed rate depends on routes, message bodies, mobile-network limits and the agreement. Treat that number as an upper platform characteristic, not a promise for every destination. The interface trade-offs are covered in SMPP versus HTTP API.

Backpressure instead of uncontrolled growth

When incoming work exceeds available delivery capacity, the system must slow producers explicitly. Options include:

• per-customer and per-class rate limits;
• a temporary-overload response;
• queue-volume quotas;
• dropping expired messages before submission;
• rescheduling bulk campaigns;
• a circuit breaker during route degradation.

Do not send an OTP after its TTL merely to clear the queue. An obsolete code creates confusion and cost without a useful result. TTL and re-issuance rules belong to the secure SMS OTP architecture.

Scaling consumers

More workers help while the bottleneck is inside your application. They cannot remove a platform or carrier limit. Excessive concurrency may instead increase errors and retries.

Scale using several signals:

• oldest-job age;
• arrival and completion rates;
• work in progress;
• throttling and transient-error rate;
• external API latency;
• remaining quota for the affected route.

Set an upper instance limit and scale down gradually after a peak. For SMPP, account for session count, window size and provider-confirmed constraints.

Make the load test resemble production

Sending one short body to one test number proves basic connectivity only. A useful test covers:

1. the real mixture of traffic classes;
2. templates with varied lengths and encodings;
3. several operator destinations;
4. a sudden peak and recovery from a pause;
5. transient faults, throttling and delayed DLRs;
6. a bulk campaign running alongside OTP;
7. growth to the point of controlled degradation.

Do not use real customer numbers without an agreed test environment. A provider may offer test routes, but their behaviour still needs to be mapped to production constraints.

Acceptance indicators

Record results per service class rather than as one aggregate:

• P50/P95/P99 queue time;
• P95 event-to-platform-acceptance time;
• percentage submitted before TTL;
• maximum sustainable rate without queue growth;
• recovery time after a burst;
• throttling, transient and permanent failure rates;
• cost per user message including segments and retries.

Measure final DLR and business conversion separately using the guidance on SMS deliverability and metrics. Higher technical throughput is not valuable if messages arrive too late or target the wrong audience segment.

Practical conclusion

SMS capacity planning starts with the real traffic profile and segment count. The team then reserves capacity for urgent classes, introduces backpressure, limits retries and tests recovery from a burst. This makes delay predictable and prevents bulk traffic from displacing OTP.

Before connecting QuickTel, prepare a table of destinations, templates, peaks and SLOs. It provides the basis for agreeing the interface, quotas, redundancy and a load-test programme for the specific project.