Software Development

Async systems with sync clients

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.
 
 
 
 

Integration Strategies

We can fix the mismatch of communication styles through a couple of strategies.

Polling

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.

Hiding asynchronicity

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.

law_enforcement

Reference: Async systems with sync clients from our JCG partner Felipe Fernandez at the Crafted Software blog.

Felipe Fernandez

Felipe is a developer interested on creating well-crafted software, not only for users, but for future maintainers too. He believes that simple, clean and expressive code should be an ethical standard for the software industry and will mentor that concern. Felipe is a strong believer in the power of social communities and thinks that one of the pillars of professionalism lies in sharing knowledge and caring about the health of the industry.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button