I am designing communication system that will be sending targeted based SMS (ads/offers) to its customer. The basic system with low load scenario works well, and the SMS sent are based on an event like a person visiting a place, he should get all the promotions done by that store or stores near him based on his interest.

But this use case changes with bulk messaging for the holiday season. Although we can subset user interest vs the number of destination and can send a bulk message using an SMS sending API with 1000 destination.

This going to reach 5 million. How should I scale my system to communicate with the SMS sending API for this quantity of load.

  • 4
    Talk to the SMS API vendor. They may have ideas on how to best approach this. You might need to spread the load across multiple SMS API's. Commented Nov 16, 2017 at 12:33
  • 1
    It's not clear in your question where the bottleneck is. Is the bottleneck the network connection between your servers and the SMS API? Is the bottleneck the SMS API itself? Or is the bottleneck how quickly you can organize what SMS messages need to be sent? The answer really depends on what is limiting how quickly you can send the messages. Commented Nov 16, 2017 at 14:42
  • The bottleneck is a theory or a preparation for the worst case. We were suspecting that the messages sending communication would be choked up during peak sale time. The choke point is the communication between our application and the SMS sending API. There is the various factor like n/w speed between the server + the number of messages the API can process per request and respond. How may split into 5 million + number of failed retry ... may more how will schedule for peak + load on server etc..
    – Ameya
    Commented Nov 20, 2017 at 9:56

1 Answer 1


Probably I didn't get the whole point, but what's the problem with horizontal scaling? Just don't send sms in the same process (in case of php) or thread (in case of java). Thus you don't make your user wait and you don't waste your resources intended for synchronous request processing. So send your sms asynchronously. Factor this sms-sending capability in a separate physical machine(s), put a load balancer behind it and scale it as much as you like. Since there is no data modification involved, the process is pretty straightforward: just add physical resources, i.e., servers.

  • SMS sending is not a sequential processor it does not interact with the user. The user interests are recorded in the system and based on some trigger (like 23 Nov one day before the black Friday date) in scheduler SMS sending jobs are triggered. The system is not the choke point here but the connection to the SMS sending API.How do you push out such large volume of communication so that we meet the deadline before midnight ?
    – Ameya
    Commented Nov 16, 2017 at 10:01
  • My solution targets this problem. Say, if you have only one process/thread that call SMS API, than it'll take forever to send all your messages. If you'd use two processes/threads, it will either. So use 1000 processes/threads. If it's not possible to deploy these resource in one server, use more servers. The only tricky thing here is not to send the same sms twice. I use postgres, and it has exactly what I need in this case: pg_try_advisory_lock. Commented Nov 16, 2017 at 10:26
  • 1
    In the most extreme, if you have very lightweight processes/threads (e.g. on Erlang/BEAM), you can just spin up 5 million processes concurrently, each of which is responsible for delivering exactly 1 SMS. (Erlang/BEAM can trivially deal with 10s of millions of concurrent processes.) Commented Nov 16, 2017 at 11:16
  • @JörgWMittag You might want to mention that an Erlang "process" is not an operating system "process". Commented Nov 17, 2017 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.