In #softwareengineering, there is a concept of synchronous and asynchronous processing. This article aims to provide a layman's introduction to this concept.
******* Not-so hypothetical scenario *******
You go to a movie theatre. As usual, you arrive late :-). But before entering the theatre, you stop at a stall to get some cheese sandwiches and more. There is a big queue waiting. you are at the end of the queue.
******* Synchronous mode *******
At the counter, there is just one person taking care of billing and making the sandwich. The person takes the order and then goes away from the counter to prepare the sandwich.
While the guy at the counter is "processing" a request, the others in the queue wait endlessly.
In the end, the "throughput" of the stall (number of customers processed per minute) is extremely less.
However, the stall owner does not have to spend money to pay for other "resources" as he processes only one at a time.
******* Asynchronous mode *******
There is one person for billing and one (or many) in the kitchen for sandwich making.
The person takes the order and passes the request to the kitchen (another thread) for processing.
The billing person politely requests you to move to the pickup counter for receiving the order.
The stall does more sales eventually.
So, you might say - one should *always* design systems for asynchronous processing right? WRONG!
****** So which one is better? ******
The answer really depends on a number of parameters such as
the complexity of the task,
your expected throughput,
expected load,
and last but not the least your budget :-)
Where synchronous is preferred more than asynchronous ...
Imagine the guy sells pre-cooked samosa, the time taken to sell samosa to one customer is not that long and he does not need to offload that task to another thread (complexity of the task). Synchronous works just fine in this case.
Synchronous is also applicable when there are not many customers on a particular day (load) and he can possibly survive with lower throughput.
If the stall owner cannot afford to pay for a chef, then he has to live with synchronous processing (Budget).
Asynchronous processing challenges
Asynchronous has its limits as well! for every 5 customers, the kitchen probably needs to add one extra chef to process the requests fast (scale-up) lest the billing counter starts to feel the "back-pressure" as queue-depth increases.
However, after a certain point, the kitchen is so full that there is no room for another chef.
At this point, the stall owner has to probably expand to another kitchen (scale-out) or risk getting his reputation spoilt with his customers.
Conclusion
In conclusion, both synchronous and asynchronous processing have their own use cases and are powerful in their own way. Where they can be deployed is really dictated by various parameters, many of which were covered in this article.