Introduction

When deciding to develop a microservice architecture, one of the main questions that come to mind is if we should follow a synchronous or an asynchronous approach for our service communication. The answer to that question will mainly be driven by the nature of our service operations and also the performance characteristics we require from the system. The general properties for each communication style are as follows.

• Synchronous
• Better for read-heavy service operations
• Generally provides immediate data consistency
• Potential for moderate scaling
• Tight coupling between services
• Simpler to design
• Requires special constructs such as circuit breakers to avoid cascading failures due to high load
• Asynchronous
• Better for write-heavy service operations
• Generally provide eventual data consistency
• Potential for higher scaling
• Loose coupling between services
• Comparatively more complicated to design
• Naturally resilient to traffic bursts and failures

As we can see from the above properties, there is no single approach that is suitable for all scenarios. The software system needs to be modeled closer to the majority of the requirements matched in each approach. There can also be scenarios where a hybrid approach will need to be followed in order to satisfy different requirements in the system. The Ballerina programming language has core features built-in that can be used to build microservices in either of the two patterns. In the following sections, we will look at the features and technologies provided by Ballerina in supporting these methodologies.

Synchronous

The most popular synchronous communication technique is using REST with HTTP. Ballerina contains rich support in creating HTTP-based services, and clients, which has inbuilt features such as data binding, mutual SSL, multipart MIME support, and out-of-the-box filters and interceptors for technologies such as BasicAuth, JWT, and OAuth.

In Ballerina, the language contains a service abstraction, which is used to model both synchronous and asynchronous communication-based services. For example, we write Ballerina services for both HTTP and WebSocket based communication. The differentiation of the communication technique is done using the way we implement the resources inside services. Let’s take a look at how a simple HTTP service is implemented using Ballerina.

HTTP

A Ballerina service is created using the service construct, and its type is decided by the listener that is associated with it. In the code in Listing 1, it shows a Ballerina service which is associated with an HTTP listener, thus making it an HTTP service. Individual resource functions in the service represent distinct sub-contexts of the base path of the service. The caller parameter in the resource represents the HTTP client or the caller who has initialized the request. This object is used in communicating back to the caller, as we see here with the respond remote method invocation.

#microservices #performace #ballerina #asynchronous communication #synchronous communication