When it comes to cloud services (or any IT services for that matter), there tends to be a lot of contradicting opinions and ideas on how to use them best.
It’s easy to get confused, but when in doubt, the best course of action is to get back to the basic principles of the solution and truly understand the trade-off and constraints of the decision you’re about to make.
I’ll address that approach in this article, which deals with one of the common dilemmas related to cloud services – choosing between synchronous and asynchronous communication.
- What’s the difference between synchronous and asynchronous processing?
- What benefits and trade-offs can we expect from each of the options?
- What communication services are offered by Azure?
Synchronous and asynchronous communication: what’s the difference?
Before we move forward, let’s clarify the difference between synchronous and asynchronous communication.
Synchronous processing
In the synchronous flow, the connection remains open from the moment the request is submitted to the server by the client. The client waits until the server sends back a response.
A real-life equivalent to this situation is when you go to a website and must wait for it to load and return the content to you. A more casual example is calling your friend on a cell phone. You know immediately whether he is available for a conversation (picks up), or not (doesn’t pick up). When you talk, you get an immediate response to your questions.
Asynchronous processing
In case of the asynchronous flow, the client doesn’t wait for the response to the request, only for the confirmation that the request was received by the server. For example, when you place an order in an online store and get an e-mail confirmation – it doesn’t have to be sent immediately, because you don’t wait “here and now” to receive it.
Another example of asynchronous communication are text messages. The only information you get immediately is whether the message was delivered. You wait for the response, which may take several minutes or a couple of hours.
Now, let’s consider the benefits and trade-offs of each approach.
Synchronous vs asynchronous processing: benefits
Synchronous processing benefits:
- “You can talk at the same time“: It provides real-time interaction with clients
- “You can focus on one recipient“: It’s easier to develop and monitor
- “You can use voice call or video call“: Many communication standards are supported (in case of cloud solutions: REST, gRPC, GraphQL)
Asynchronous processing benefits:
- “You can write a second message after sending the first one”: It decouples workload
- “You can read messages whenever you want”: It provides resilient message handling
- “If there are too many messages you can plan how to process them”: It supports load level control and deferred processing
- “Your inbox has a large capacity”: It provides storage for many messages
Synchronous vs asynchronous processing: trade-offs
Synchronous processing trade-offs
- “You can only talk to one person at a time”: The server may have to deal with many concurrent connections because each concurrent client maintains an open connection while waiting for the results.
Solution: In such a scenario, it is wise to consider building a mechanism that can automate and scale up your solution, including services such as Load Balancer, Service Discovery, and API Gateway.
- “Your recipient is not picking up the phone”: Due to slow network connections, timeouts, or unavailability of resources, the request can fail. The server has to provide a mechanism to detect the failure and try to repeat the request.
Solution: A level of tolerance for reduced functionality during unavailability is a business decision. Some kinds of faults are self-correcting, and if the action is repeated after a suitable delay, they’re acceptable. Patterns such as retry policy and circuit breaker can help to deal with it.
Asynchronous processing trade-offs
- “You need to wait for an answer”: Using asynchronous communication, you don’t have a real-time interaction with the recipient. You must accept that the changes you make will be visible after some delay. On the other hand, you have a guarantee that all messages will be delivered
Solution: It is worth distinguishing between business processes that require immediate change, and those where the change must be consistent after a minimum delay.
- “The telecommunication network is down and your phone doesn’t have a signal”: If you have one centralized component in your solution, you should take care of its scalability, recoverability, changeability, resilience and interoperability. It’s necessary to make sure your centralized component is ready for any type of failure, and it will not block business processes.
Solution: Consider using backups and disaster recovery processes
- “Sometimes you wait so long for an answer that you don’t need it anymore”: Your messages were delivered but some services were not able to process them correctly (which can be due to the short period of unavailability of the service). Together with your business, you need to decide what to do with the messages that didn’t proceed because of such issues (poison messages) or which are outdated and proceeding them doesn’t make sense and may cause serious problems.
Solution: Find a way to deal with expired and poison messages.
Modeling to the rescue
You should ask yourself: which benefits, and trade-offs can I live with? The answer will come if you model the business process first.
Define what needs to be done and ensure the realization of targeted business goals and strategy. This is critical for transforming goals into projects and outcomes that maximize value, according to defined priorities. Analyzing business and technical requirements allows for preparing a balanced architecture solution.
Many industrial processes, techniques, and tools are based on modeling that provides us with the representation of the system. In Predica, we use a number of them in order to deliver the best quality solution vision, architecture, and backlog. It involves three methods that are most commonly applied: Design Thinking, Event Storming, and C4 model.
Asynchronous messaging services in the cloud
In Azure, we can differentiate between two types of PaaS solutions that can offer messaging functionality: Azure Storage Queue and Azure Service Bus.
Azure Queue Storage is a service that allows you to store large numbers of messages. Azure Service Bus is a part of a broader service that supports queuing messages and more advanced integration capabilities. It is more complicated than Queue Storage but also provides more flexibility.
Storage queues and Service Bus queues differ in their features. Depending on your solution, you may select one or both options. Queues are the core of the asynchronous communication capabilities of the services because using them means that producers and consumers don’t have to send and receive messages at the same time.
You can find the full comparison of services here.
SUMMARY
None of the communication styles is a silver bullet. They both require dealing with consequences meaning spending time and money to cover some crucial areas. Each communication style offers an opportunity to achieve certain benefits.
Communication flow is just one of many decisions you have to make, before building an IT solution. In my previous article, I elaborated on how to start thinking about and defining the proper architecture for an IT solution. The process there is handy and easy to use, so I encourage you to check it out.
I hope now you understand the difference between synchronous and asynchronous messaging. If you’ll still have trouble with this type of architectural dilemma, don’t hesitate, and check out our dedicated offer. Based on our experience with numerous simple and complex projects, we have built up a large stockpile of knowledge and expertise, which allow us to choose the most balanced architecture for each individual solution, show options, and explain when to apply them.
