How to implement feature flags and filters in .NET apps? A step-by-step guide
Along with improved DevOps expertise comes a better performance of delivery teams. And when many deployments take pl...
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.
Before we move forward, let’s clarify the difference between synchronous and asynchronous communication.
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.
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 processing benefits:
Asynchronous processing benefits:
Synchronous processing trade-offs
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
Solution: It is worth distinguishing between business processes that require immediate change, and those where the change must be consistent after a minimum delay.
Solution: Consider using backups and disaster recovery processes
Solution: Find a way to deal with expired and poison messages.
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.
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.
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.
Read similar articles