Key takeaways
- Capacity is not only messages per day. It is how many you can send per second when a campaign or an alarm hits.
- Keep one-time codes and alerts separate from campaigns, so they do not wait in a queue behind a newsletter.
- Operator networks have their own limits, so spread large sends over time and plan them with your provider.
- Tell the provider the volume, countries, timing and message type in advance, and start with a small share of the list.
Which peaks should you plan for?
Some peaks you know in advance, others arrive without warning. Each needs its own preparation.
- Black Friday and sales: campaigns, order confirmations and delivery updates all rise at the same time
- Payday and the turn of the month: many customers log in, pay and receive codes within a few hours
- Newsletters and campaigns sent at a fixed time to the whole list at once
- Alarms and service notices that must reach many people quickly, for example during an outage
What does “millions of messages a day” say about your peaks?
A daily volume shows that a platform is built for large amounts. It does not show what happens when you want to send, say, 400,000 messages in ten minutes. That depends on the whole chain from your system to the handset, and the chain is only as strong as its weakest link.
| Link | What can limit it | What you can do |
|---|---|---|
| Your own system | How fast you can build and send messages | Use a queue and bulk requests |
| The provider’s API | Limits on requests per minute | Know the limits and ask for them to be raised in good time |
| The provider’s routes | Capacity per route and destination | Tell the provider the volume and ask about more routes |
| The operator network | The operator’s own limit on how fast it accepts messages | Spread the send over time |
| The handset | Switched off or out of coverage | Set a validity period and have a fallback channel |
How do you keep campaigns away from codes and alarms?
When there are more messages than can be sent at once, a queue forms and the waiting time grows. For a one-time code, a minute is often too long. Traffic therefore has to be prioritised, and the provider can also pace sending per operator (throttling), so that one slow operator does not hold up the rest.
- Split the traffic: send codes, receipts and alarms apart from marketing, with their own senders or number series and, where the provider supports it, their own keys
- Ask whether codes are placed ahead of campaigns in the queue or whether they share one
- Send campaigns in waves: cut the list into batches and send them at a steady pace instead of all at once
- Avoid known peak times: do not send a newsletter just when you expect many logins
- Keep an emergency brake: schedule sends so that they can be cancelled or paused before they go out
- Retry only on clear failures, with increasing pauses, and give every message an ID so that a retry does not become a duplicate
What should you tell the provider in advance?
The more the provider knows, the better it can prepare routes and capacity. Send it in writing several days before a large send.
- The total number of messages and the number per minute at the peak
- Which countries are involved, and the split across operators if you know it
- The date, start time and duration, with the time zone
- The message type (transaction or marketing), text length and sender
- Whether codes and alarms run at the same time, and which messages must not wait
- Who can be reached during the send, and what happens if something goes wrong
How do you test and follow a large send?
Test your own chain first: the queue, the sending and the webhooks for status updates. Use test keys for that, if your provider has them. Agree with the provider how you can test against real routes, and do not load-test live traffic without an agreement, because it can trigger filters or look like abuse.
Start with a small share of the list, for example one percent, and read the delivery reports by country and operator before you send the rest. During the peak, follow:
- The share of messages that are accepted but not yet delivered, because it shows how long the queue is
- Delivery rate and time to deliver by country and operator
- Failure reasons that suddenly rise
- The balance, if you use prepayment: if it runs out mid-send, new messages are rejected
How ZafeConnect fits
ZafeConnect carries millions of SMS every day. The API accepts single messages and bulk requests of up to 10,000 messages; each API key can make 1,000 send requests per minute, and bulk requests are limited to 100 per minute. Behind that are multiple upstream providers and failover systems.
Tell us the volume, countries and timing in good time, and we will confirm the setup for you and plan a large send with you. Ask specifically about your scenario, for example how many messages per second you need.