When it comes to service collaboration, deciding whether to opt for synchronous or asynchronous communication is one of the most vital choices to make. This decision significantly impacts implementation details.
Synchronous communication necessitates making a call to a remote server that temporarily suspends execution until the operation finishes. Conversely, asynchronous communication enables the caller to return without waiting for the operation to complete and might not place priority on whether or not the operation concludes.
Synchronous communication is often more straightforward to comprehend. We can easily determine if operations have concluded successfully or not. In contrast, asynchronous communication can be highly advantageous for long-running tasks, where it's impractical to keep a connection open between the client and server for an extended period. It's also beneficial for situations where low latency is crucial, and blocking a call while awaiting a response can significantly slow down the system. In the context of mobile networks and devices, firing off requests and presuming that they have succeeded (unless notified otherwise) can ensure that the user interface remains responsive, even if the network is sluggish. However, it's worth noting that handling asynchronous communication may require more complex technology, which we will delve into shortly.
There are two primary modes to consider: synchronous and asynchronous. Each mode can facilitate distinct idiomatic styles of collaboration, either request/response or event-based.
Request/Response Communication (Orchestration)
In the request/response model, a client initiates a request and waits for a response. While this approach is well-suited for synchronous communication, it can also work in the context of asynchronous communication.For instance, a client might launch an operation and register a callback, requesting the server to notify them when the operation is complete.
Event-Based Communication (Choreography)
In an event-based collaboration, we take a different approach. Instead of a client initiating requests for specific tasks to be performed, it informs other parties that a particular event has occurred and expects them to act accordingly. Unlike request/response collaboration, we never instruct anyone else what to do. Event-based systems are inherently asynchronous, and the business logic is more evenly distributed among the various collaborators instead of being centralised in a core system. Furthermore, event-based collaboration enables high decoupling. The client emitting an event has no knowledge of who or what will respond to it, meaning that new subscribers can be added to these events without the client's involvement.
Real life example
Let’s take an example from a real-life banking software , and look at what happens when we create a customer:
- A new record is created in the loyalty points bank for the customer.
2.Our postal system sends out a welcome pack.
3.We send a welcome email to the customer.
In terms of implementing the flow, there are two architectural styles to consider. The first is orchestration, which relies on a central system to guide and control the process, similar to a conductor leading an orchestra. The second style is choreography, where each component of the system is informed of its role and allowed to determine the details of its own execution, similar to dancers in a ballet who find their way and respond to others around them.
Let's consider how an orchestration approach could be applied to this flow. In this scenario, the most straightforward solution would be to designate the customer service as the central control point. When a new customer is created, the customer service would communicate with the loyalty points bank, email service, and postal service using a series of request/response calls, as shown in Figure 1.2.
The customer service itself can then track where a customer is in this process. It can check to see if the customer’s account has been set up, or the email sent, or the post delivered.
The downside of the orchestration(request/response) approach is that it can lead to the customer service becoming a centralised governing authority. It can become the focal point of a web, and a central location where the logic is concentrated. I have observed this approach leading to a few intelligent "god" services dictating to weak CRUD-based services.
Choreographed Approach
In an alternative approach, choreography, the customer service could emit an asynchronous event saying "Customer created" instead. The email service, postal service, and loyalty points bank would then simply subscribe to these events and respond accordingly, as shown in Figure 1.3. This method is much more loosely coupled. If another service needed to respond to the creation of a customer, it would simply subscribe to the events and perform its job as required. However, the downside is that the explicit view of the business process depicted in Figure 1.2 is now only implicitly represented in our system.
With that approach implies that there is a need for extra effort to ensure that you can keep an eye on and verify that the necessary tasks have been completed. For instance, would you be able to identify if the loyalty points bank encountered an error and failed to set up the correct account? One strategy that I find useful in addressing this issue is to create a monitoring system that aligns explicitly with the business process view in Figure 1.2. However, this system also tracks the actions of each service as independent entities, enabling you to map any unusual exceptions onto the more explicit process flow.
In my experience, systems that lean towards a event-based (choreographed) approach are typically more flexible, loosely coupled, and adaptable to change. However, additional effort is required to monitor and track the processes across different systems. Conversely, heavily orchestrated implementations can be very fragile and have a higher cost of change. For this reason, I highly recommend striving for a choreographed system, where each service is intelligent enough to comprehend its role in the overall process.
On the other hand synchronous communication is straightforward and provides immediate feedback on the success of a call. However, if we prefer the request/response model but are dealing with processes that take longer, we can initiate asynchronous requests and wait for callbacks. On the contrary, adopting an asynchronous event-based collaboration allows for a choreographed approach, resulting in more decoupled services. This is desirable as it ensures that our services can be released independently of each other.
Subscribe to newsletter for more :
https://architechinsider.substack.com/
Top comments (0)