Async Systems with Sync Clients
Async Systems with Sync Clients
We don't always write systems that are all dealing with exclusively-synchronous clients, and similarly for exclusively-asynchronous clients. What happens when we start mixing the two? Find out how to deal with this situation here.
Join the DZone community and get the full member experience.Join For Free
The State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.
As the Reactive Manifesto says Reactive systems are: Responsive, Resilient, Elastic and Message Driven. The last principle often goes together with non-blocking async protocols. This style of communication "allows recipients to only consume resources while active, leading to less system overhead". This fits perfectly with new demands of efficiency derived from the elastic model of cloud providers. However not every system is async and integrating an async system with a sync client could be tricky.
We can fix the mismatch of communication styles through a couple of strategies.
This involves work for both parties. First round trip of this protocol involves client sending some request to the server with an outcome of ACK/NACK. This is called fire and forget. Assuming HTTP, the server will return status code 202 (Accepted). The async process will eventually succeed or fail and that result will be exposed by the server in a different endpoint. Client will have to periodically poll that endpoint to figure out the status of the operation.
Polling is by nature inefficient but could be a good solution when the technological stack doesn't allow bidirectional protocols like Web Sockets.
If we don't have control over those clients, we'll probably have to hide our async nature under some sync layer. That layer will implement a polling or pub/sub mechanism bounded by a timeout.
Learning by example
In this series of posts we'll implement last strategy with a pub/sub mechanism. We'll add some essential complexities to our domain to make the exercise more juicy.
We'll be working on something similar to Craiglist, a website with classified advertisements. However our platform will have a focus on social (as everything nowadays). That means that a user can post an item into some group and/or to her followers. People can report dubious items and we will take seriously those reports as they're threats to our reputation. So much so that the authorities have direct access to an API that can take down an item immediately.
Our system is formed by several microservices based on Akka, using Kafka for inter-process communication. Police platform has only sync clients and they don't seem keen to implement a polling mechanism to verify that an item has been actually removed. We need to communicate with them synchronously and that's not negotiable. In next posts we'll see the details of our solution, but as an advancement, let's see the high level architecture. Don't worry if you don't understand everything yet.
Published at DZone with permission of Felipe Fernandez . See the original article here.
Opinions expressed by DZone contributors are their own.