How to Size TPS, Queues, and Capacity for A2P SMS Traffic Peaks
An operational guide to calculating TPS, sizing queues, separating priorities, and testing A2P SMS sending capacity without confusing acceptance, DLRs, and final delivery.
The operational question: how much TPS does an A2P SMS operation really need?
Sizing TPS is not about choosing a single number for the entire platform. The useful question is: how many messages must be accepted, processed, and sent within a specific operational window, for a specific mix of destinations and traffic classes?
Required TPS should be derived from expected volume and the target window. As a starting point: base TPS = expected messages / seconds in the window. This formula is useful for planning; it is not a capacity guarantee for an HTTP API, an SMPP session, a provider, a route, or a mobile network.
The resulting figure should be documented together with its assumptions: time distribution, destination mix, traffic priority, retry policy, expirations, and confirmed limits for each connection or route. Without these assumptions, an aggregate TPS figure can conceal a relevant bottleneck.
- Define what “within the window” means: internal acceptance, provider acceptance, or reported final status.
- Calculate by traffic class and destination, not only for the aggregate total.
- Treat headroom as an explicit decision for bursts, retries, and route variation, not as an implicit guarantee.
- Validate effective limits with the provider or operator managing each capacity.
Defining the peak: volume, window, time distribution, and destinations
Daily or monthly volume does not size a peak. Two operations with the same volume may require very different capacities if one distributes sends over hours while the other must issue them within minutes. The unit of analysis should be the event’s time profile, preferably by minute and, where required, by second.
Separating destinations is equally important. Volume concentrated in one country, network, numbering range, sender, or route can reach limits before the platform total does. Destination numbers should be managed using normalization consistent with the international E.164 numbering plan and the routing rules applicable to the integration.
Authentication peaks are often linked to simultaneous user actions or access incidents. Campaigns may be synchronized around a launch time. Both cases require a realistic arrival profile rather than a daily average.
- Expected messages per time interval.
- Target window by traffic class.
- Distribution by country, network, route, and sender.
- Expected percentage of OTP, transactional, and campaign traffic.
- Events that may create bursts: launches, releases, access recovery, or batch processes.
- Expected retries and the conditions that trigger them.
Distinguishing four capacity limits
An interface acceptance response does not prove that a message has completed its journey to the recipient. To operate accurately, separate at least four stages: HTTP API or SMPP acceptance, internal processing and queueing, provider acceptance or processing, and the final status reported by the SMS delivery chain.
In SMPP, submit_sm and submit_sm_resp reflect the exchange between the ESME and the SMSC. The subsequent outcome may be reported through an SMSC Delivery Receipt when requested. Therefore, accepted submit_sm TPS must not be presented as delivered TPS or as proof of handset receipt.
This separation also improves troubleshooting. If local acceptance remains stable but the internal queue grows, the limit lies before outbound dispatch. If pending requests increase or responses degrade, the issue may be in the connection or at the remote endpoint. If final status changes by destination, it should be assessed by route and network, not only as a global average.
- Acceptance limit: requests the interface accepts.
- Processing limit: capacity to validate, queue, prioritize, and dispatch.
- Provider or route limit: confirmed technical and contractual capacity for each destination.
- Network behavior: final statuses and timings that may vary across the delivery chain.
Base TPS calculation and documented headroom
The initial calculation is straightforward: divide the number of messages that must be processed by the available seconds. For example, if an operation must accept and dispatch a batch within a given window, base TPS represents the minimum average rate for that window. Then compare that rate with the time profile: if arrivals are concentrated at the start, the inbound rate may significantly exceed the average.
Headroom should not be selected as a universal figure. It should address a specific assumption: an initial burst, session recovery, a temporary increase in requests, destination redistribution, or controlled retries. It is better to record several scenarios—expected, high, and contingency—than to hide all risks behind a single multiplier.
The calculation should be repeated for each operational partition. A platform may have sufficient aggregate capacity while still lacking the required capacity for a particular destination or route.
- Base TPS = expected messages / seconds in the window.
- Calculate inbound TPS and outbound TPS separately.
- Add headroom only with an identified operational cause.
- Compare the result against limits by route, destination, connection, and traffic class.
- Review the calculation when the destination profile, window, or retry policy changes.
Why averages are misleading
An average smooths out the very behavior that causes incidents. If thousands of requests arrive simultaneously, a daily average does not explain the required queue depth or the age messages will reach. The design must consider the difference between arrival rate and sustainable outbound rate in every interval.
Destination concentration also matters. Sending to multiple destinations is not equivalent to sending the same volume to a single network. Specific limits are not standardized by SMPP or HTTP: they must be understood through applicable documentation, operational agreements, and observation of the real route.
For OTPs, prolonged waiting can also turn a technically processable message into a useless one. Therefore, a peak is not managed simply by increasing queue capacity; it requires deciding which traffic is admitted, which is delayed, and which must expire in a controlled manner.
- Analyze maximums per second or minute, not only averages.
- Measure concentration by destination, route, sender, and traffic type.
- Model the initial arrival pattern of campaigns and authentication events.
- Define the point at which each message class is no longer useful.
Sizing queues: depth, age, and expiration
Required queue depth depends on the temporary excess of inbound traffic over sustainable outbound throughput. An operational approach is to calculate the maximum accumulated difference between arrival rate and service rate during the peak. If more messages arrive than can be sent, the difference accumulates; when outbound throughput again exceeds arrivals, the queue drains.
Queue depth alone is not sufficient. Set a maximum acceptable age for each traffic class. A queue may hold every message and still fail the usefulness requirements of an OTP or a time-sensitive transactional notification. Age should be measured from a defined and consistent timestamp, for example, from the platform’s acceptance of the request.
SMPP allows a validity_period to be specified, representing an expiration time at the SMSC after which the message should be discarded if it has not been delivered. This capability does not replace application-level functional expiry: the platform should prevent messages with no remaining value from staying unnecessarily in internal queues or competing with critical traffic.
- Calculate the maximum expected accumulation during the peak.
- Set an age limit for each traffic class.
- Define what happens when the age limit is exceeded: cancel, expire, or notify the originating system.
- Align internal expiry with validity_period and provider rules where applicable.
- Measure depth and age by queue, destination, and priority.
Separating OTPs, transactional messages, and campaigns
OTPs, transactional traffic, and campaigns should not share a single queue without controls. Classification is a product and operations decision, but it must translate into explicit admission, priority, capacity reservation, expiration, and degradation policies.
OTPs usually require a very short functional age. Transactional messages may have different tolerance depending on the business process. Legitimate, consent-based campaigns, by contrast, are often candidates for more flexible scheduling when capacity is under pressure. The policy should be understood by product, operations, and the systems originating the messages.
SMPP includes priority_flag and service-related fields, but the standard does not prescribe a queueing policy or guarantee that a priority marker will produce the same outcome across implementations. Priority should be applied primarily within the platform and coordinated with route conditions.
- Reserve capacity or admission for critical traffic where necessary.
- Prevent a campaign from consuming the queue or capacity intended for OTPs.
- Assign maximum age and expiry action by class.
- Record the reason for each degradation for later analysis.
- Keep sends legitimate, consent-based, and subject to applicable rules.
Latency budgets and DLR semantics
A useful latency budget breaks the journey into observable stages: time to HTTP API or SMPP acceptance, time waiting in the platform’s own queue, time to provider acceptance or processing, and time to the reported final status. Each stage should have its own timestamp, source, and correlation method.
Do not equate the initial response with final receipt. In SMPP, the response to submit_sm confirms the request exchange with the SMSC, while the subsequent outcome is reported through a delivery receipt when requested. Statuses may include, among others, DELIVRD, EXPIRED, UNDELIV, and REJECTD.
Not all delivery reports have the same semantics either. 3GPP distinguishes reports issued by the Service Centre from those issued by the mobile station. Therefore, a DLR issued by an SMSC or an intermediary network should be labeled by its issuer and meaning. It must not automatically be presented as independent evidence of handset receipt.
- Measure latency by stage, not only as a total time.
- Use percentiles to identify long waits and queue degradation.
- Retain the source of the status: platform, provider, SMSC, or another party in the chain.
- Differentiate acceptance, reported final status, and handset receipt when evidence of that nature exists.
- Avoid promises of final receipt based solely on an initial response or on a DLR with unconfirmed semantics.
Frequently asked questions
How is the TPS required for A2P SMS calculated?
As a starting point, divide expected messages by the seconds in the target window. Then calculate by destination, route, connection, and traffic class, and separately document headroom for bursts, retries, and operational variation. The result is a planning requirement, not a network capacity guarantee.
Does a successful submit_sm_resp mean the SMS reached the phone?
No. submit_sm_resp reflects the response to the SMPP request between the ESME and the SMSC. The later outcome requires observing the delivery receipt when it has been requested and analyzing its status and semantics. A DLR issued by an SMSC does not automatically prove handset receipt.
How is the size of an SMS queue calculated?
Estimate the maximum accumulation during intervals where the arrival rate exceeds the sustainable outbound rate. In addition to depth, define a maximum age by traffic class and the action to take when it is exceeded, such as controlled expiration or cancellation.
Why should I separate OTPs and campaigns?
Because their usefulness and waiting requirements differ. A campaign can be scheduled or reduced when capacity is under pressure, while an OTP usually loses value if it waits too long. Policies should separate admission, priority, age, and degradation.
How does SMPP affect concurrency sizing?
SMPP supports asynchronous requests and uses sequence_number to correlate requests and responses. A useful approximation is to estimate in-flight requests as target TPS multiplied by the observed submit_sm_resp latency. The final limit should be adjusted per session according to documentation, errors, timeouts, and observed provider behavior.
What precaution should be taken with HTTP retries?
A timeout or a connection closing before a response is received does not prove that the submission was not accepted. Since a submission may be non-idempotent, retries should not be automated without an idempotency identifier, a reliable status query, or equivalent evidence that prevents duplicates.
Sources consulted
- SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
- RFC 9110: HTTP SemanticsInternet Engineering Task Force (IETF) / RFC Editor
- 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)3rd Generation Partnership Project (3GPP)
- Recommendation ITU-T E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)