At PortaText we love to have our doors open so you can take a peak on how we like to build things, what kind of technologies we use, and how our infrastructure is designed to be scalable, performant, and trustable.
A few examples can be found in our previous blog posts where we discuss our microservices architecture (“How We Use MicroServices For An Awesome SMS Experience“), our messaging bus and components intercommunication (“Did you Know That RabbitMQ Is Powering Your SMS Business?“), and one of our favorite languages called Elixir (“Why We Choose Elixir To Power Our SMS Infrastructure“).
Today we are going to discuss how we use asynchronous processes internally, what kind of advantages this has for you and your business, and how they are different from synchronous processes and operations. Enjoy!
What is a synchronous operation? How is it different from an asynchronous operation?
Let’s say you need to ask a question to a colleague, your accountant, or your lawyer, so you decide to give them a call. After a small chit chat you ask your question, and at this point, one of two things may happen:
A) The other person can say something like “hold on, I have the answer right here” and you have to be online (on call) during the whole the time that it takes the other person to find and give you an answer.
This forces you to do just one thing at a time (the call) but also, if your call finishes early (perhaps you pressed the wrong button or the communication failed somehow), you have to redial and ask the question again (let’s say another person took your call, so you have to start over the whole process). This may be called a synchronous operation, you are literally waiting for an answer, and online during the whole process.
B) But another magical thing may happen. The other person might say something like “let me get back to you on that”, so you both can finish your call, carry on with your daily duties, and perhaps you get called the other day (or later that same day) with the answer you were looking for.
This is an asynchronous operation. A request is started, and although you may check for the status for that particular operation, you will essentially and eventually get the response or final status for that operation at a later time, and it’s not needed for you to regularly check on it (unless, of course, you colleagues, lawyers, or accountants are not that trustworthy!).
Asynchronicity in your regular life
As discussed in the previous section, asynchronous operations are actually everywhere in our daily life. For example: you take a test and get notified of the results later on, when you send an SMS with your mobile you just “fire-and-forget” and eventually your phone receives a confirmation for the operation.
Asynchronous operations allows you (and the one processing your request) to work offline on any pending tasks and perhaps switch between tasks before finally delivering any results. This is highly efficient for all the parties involved, because everyone gets to decide how to use their time and prioritize, pause, or resume the work at will if needed.
Jobs: Our asynchronous operations
We often prefer to process your requests with what we call Jobs. You never create a job per se, but the creation of a job is implicit in some operations. You get a Job ID from our API endpoints when:
For example you get a Job ID when:
- You create an SMS campaign by uploading a CSV file.
- When you upload a Blacklist or contact list.
- Start a Number Inspect operation with a CSV file.
- Some others as well!
These are actions that often take time to complete, we expect that you will upload a CSV with several thousand lines and we don’t want to keep you waiting while we process it.
In this way we can accept your request, and after running a few initial sanity checks give you a job id, and finally process your operation eventually, and let you know the results as soon as we finish with it.
This has a few advantages. For example: you don’t need to be online while the operation is being done, so you don’t have to wait until it finishes, and more important, the operation is not aborted if your HTTP connection to us die because one reason or another.
Also, we can retry operations on our own if we need to, or even pause and resume them if we detect that something’s up in our infrastructure.
But we also use asynchronous operations when for example you send an SMS, and we let you know the results via Notifications… eventually (i.e: when we actually have tried to route your message and/or when we have confirmation from our downstream carriers).
It’s all about Back Pressure
In our infrastructure many things happen simultaneously. We have a parallel and concurrent environment, and resources might get scarce when too many users are trying to do many things at the same time. Using asynchronous operations allow us to not overflow our systems resources and limit the number of operations per node and per resource or operation to reasonable levels, so everyone get their fair share of system use.
— The PortaText Team.