Forem: Kav

Microservice Communication - Asynchronous communication

Kav — Wed, 13 Dec 2023 15:47:45 +0000

As you remember from my last article, I have been discussing two types of microservice communication mechanisms.

Synchronous communication.
Asynchronous communication.

We have covered some basic stuff about synchronous communication (what is synchronous communication, best practices, different types of synchronous method so on...). If you didn't read the article I suggest to head over that before reading this by clicking here.

So in this article, we will be focusing more on asynchronous communication, the second type of communication mechanism. Let's start with problems of synchronous communication.

Problems with Synchronous communication.

When we do HTTP calls between multiple services (chain query),
- Increase latency with high coupling services.
- Performance, scalability and availability problems.
To avoid these problems,
- Reduce the interservice communication.
- Make microservice communication asynchronous.

Asynchronous communication.

In asynchronous communication, client sends the request and it does not wait for the servers response.
The message brokers handle the message in asynchronous manner.
The message brokers store the message until consumer consume it.
If the consumer service is dead, brokers are configured to retry until the successful delivery.
Messages in the brokers can be persist if it is required, or it could share in memory.

There is one term you should know when we talk about the message brokers. It is "Events".
Any action or occurrence in a system, that needs to communicate with the other parts of the system know as an "Event".

Benefits Asynchronous communication.

Allows to add and remove subscribers without affecting to producer service.
Can scale producers, brokers and subscribers independently.
Event driven architecture is the best way to communicate between microservices by creating and sending events to brokers and subscribing event from brokers.
If the broker is down when send the message, it can retry for successful delivery.

Types of asynchronous messaging communications.

1. One-to-one(queue) - single receiver - point to point model

If you send 1 request to a specific consumer and the operation will take a long time, it is better to use one-to-one(queue) asynchronous communication.
One producer and one consumer. Implement as a command pattern.

Ex:- RabbitMQ, ActiveMQ, Amazon SQS

2. One-to-many(topic) - multi receivers - publish/subscribe model

Producers publish an event and it consumes from zero to multiple microservices by subscribing events on the broker system.
Publishers don’t need to know any subscribers.
Events(messages) are available to all subscribers and topics can have more than one subscriber.
The messages remain persistent in a topic until they are deleted.

Ex:- Kafka, RabbitMQ, Amazon SNS and EventBridge.

Note : If a client waits for the response, we use Synchronous communication. If the client does not wait for the communication, then we use Asynchronous communication.

Fan-Out Pattern.

This refers the brokers efficiently send messages to all the subscribers.
Message Fanned out parallelly to multiple destinations.
In publisher subscriber model, publisher sends the message to the topic, message is immediately fanned out to all subscribers of this topic.
Each service can operate and scale independently and individually that is completely decoupled and asynchronously. - All components that subscribe to the topic receive every message unless a message filtering policy is set by the subscriber.

Topic-Queue Chaining and Load Balancing Pattern.

Mostly related to resilience in microservices and mostly used on serverless architecture.
Publishers publish the message with fire-and-forget. So it will lose when a microservice is down.
In the Topic-Queue pattern, we add a queue between the event bus(topic) and each of the subscribers. The queue can act as a buffering load balancer.

Note:- with using Kafka, you don't need to use an additional queue mechanism. Because, Kafka can already persist messages into clusters. When the subscribers are up and running they can consume messages that they subscribed.

Through this article, I have discussed about some of the theoretical concepts of asynchronous communication. We will discuss how to build an application with asynchronous communication (like Kafka) with our future articles. So make sure to follows, if you don't need to miss any of article. Lets meet again with another article.

Microservice communication - Synchronous communication

Kav — Thu, 07 Dec 2023 15:45:35 +0000

As you know, in the microservice architecture, each service is isolated from other services. To communicate from one service to one or more other services, we need to know about the communication mechanisms. In this article series, we will discuss about most common microservice communication mechanisms. Lets start our learning journey.

Microservice communication mechanisms can be divided into two categories.

1. Synchronous communication

Client service sends the request to one or more services and wait for the response(s) from that services.
Use HTTP(HTTPS as well), gRPC protocols for communication.
Client blocks the thread. When it receives the response the rest of the code will continue.

2. Asynchronous communication

Client service sends the request to one or more services and it does not wait for the response(s) from that services.
Use AMQP protocol.
Using AMQP protocol clients send the message with help of message broker systems like Kafka, RabbitMQ.
Messages consume from subscriber systems in async way and it does not wait for quick response.
AC can be divided into 2 categories.
- One to One (Queue)
- One to Many (Topic)

In this part, we will be more focused on synchronous communication.

Different types of communication patterns.

1. Request/Response communication.

When service A sends a request to service B, service A always wait for service Bs response.
For synchronous request/response communication - use HTTP and REST protocols
Uses to expose APIs from microservices.
If the communication between internal microservicers - use gRPC protocol. gRPC provides high performance and low latency.
If you need to define the structure of data - use GraphQL. -
GraphQL provides 1 response per request in a more flexible and efficient way.

Ex:- REST communications, GraphQL, gRPC etc...

2. Pull communication.

A service request data from another service only when it needs. This is also know as polling.

Ex:- An Order processing service pull current product data from inventory service to check the availability.

Based on HTTP, AMQP (short polling - long polling)

It’s a call-and-ask model. (also called “Polling”)

It is basically the same as refreshing your email every 5 minutes to check for new mail.

Drawback.

waste of bandwidth (if there is no new mail and a response comes from the server.)

Opening and closing connections is expensive. The model does not scale well.

Generally, we can poll an API at any time. But some applications limit API calls.

Polling can be divided into two categories.

Short polling - In short polling, the client sends requests frequently to the server to check for new update or data. Server responses to the each request even there is no any updates.

Ex:- Real-time dashboards, servers' health checks.

Long polling - The client send one request and server holds it until new data is arrived.

Ex:- Notification service

3. Push communication.

A service keep sends data to another service without asking it.
Based on the HTTP, Websocket protocol.
Use for real-time two-way one-to-many communication like chat applications.
Here, clients and servers can both send messages to each other at any time.

Ex:- A user service push updates to an email service to trigger email about user updates.

4. Event driven communication.

Asynchronous messaging pattern that use publishers and subscribers.
These microservices don’t call each other. They create and consume events in an async way through a message broker system (RabbitMQ and Kafka queues).
Use Publish/Subscribe pattern. Benefits
- Producer service does not know about its consumer service. Consumer services don't necessarily know about the producer. So, services can be deployed independently. So it’s a loosely coupled microservice. Drawbacks
- No clear central place or orchestrator; this increases the complexity of architecture.

Synchronous communication.

As I briefly explained above, when a service communicate with another service by requesting some data and it waits for the response (with requested data), it is a synchronous communication.

Lets take user login scenario as an example. First a user send a request with his email and password. Then client application sends these data to backend service and wait until its acknowledgement. If those input are valid user can log in.
This is a REST based communication mechanism. There are more synchronous communication ways that we will discuss in this article.

These microservices don’t call each other. They create and consume events in an async way through a message broker system (RabbitMQ and Kafka queues).
Use Publish/Subscribe pattern.
Benefits
- Producer service does not know about its consumer service. Consumer services don't necessarily know about the producer. So, services can be deployed independently. So it’s a loosely coupled microservice.
Drawbacks
- No clear central place or orchestrator; this increases the complexity of architecture.

Synchronous communication and best practices

In synchronous communication, clients send a request and wait for a response.
Communication protocols can be HTTP or HTTPS. should follow the HTTP/REST protocol (can be extended with gRPC and GraphQL).

Different types of synchronous communication methods

In this section, I will be discussing briefly some popular synchronous communication methods.
I will discuss each of this method deathly in my future articles.

1. RESTful applications.

Applications that use HTTP/REST for communication.
There are some rules to define RESTful APIs as below.
You can refer @ksound22 REST API Best Practices – REST Endpoint Design Examples for better patterns.
Benefits
- Requests can simply be sent using browsers.
- HTTP protocol
- HTTP GET has organic (built-in) caching options.
- JSON representative request-responses
- Provide better scalability.
Drawbacks
- Send multiple requests to get relational data.
- Chatty communication when enriching data.
- Over-fetching (providing additional information that is not required) and under-fetching requests are hard to implement and require multiple calls.

2. GraphQL

It is a query and manipulation language. It allows us to define the structure of the required data.
It provides access to many sources with a single request. So it reduces the number of multiple network calls.
Core concepts
- Schemas - Describe all the possible data that clients can query on it.
- Resolvers - Those are the functions that attach to fields in a schema. During executions, resolvers call to produce the values.
- Mutation - GraphQL operations (allowing the insert of new data and modification of existing data)
Benefits
Can get exactly what you need.
Can get many resources in a single request.
Evolve APIs without versioning.
Fast and quick response time (because it reduces the number of calls to get data)
Strongly typed (define types before querying). It reduces miscommunication.)
More flexible with schema and type systems
Drawbacks
- Query complexity. When accessing multiple fields in a single query, it may request too much-nested field data at a time. This causes performance problems)
- Caching (complicated to implement a simple cache in GQL when compared to REST)
- Rate Limit. (It is difficult to allow a specific number of requests at a specific time.)

Issues with both REST and GraphQL

Network performance issues affect inter-service communication.
Backend communication performance requirements
Real-time communication requirements
Streaming requirements.

3. gRPC - Google Remote Procedure Calls

There are two kinds of APIs.
Public APIs - User HTTP REST. APIs should be human-readable.
Backend APIs - Use gRPC. The Importance of backend APIs is network performance instead of human readability.
gRPC is used to communicate between services, efficiently and independently in their preferred languages.
Focused on high performance. For that, it uses the HTTP/2 protocol to transport binary messages.
- HTTP/1 opens HTTP calls for a request. (HTTP/2 provides long lasting connection)
- HTTP/1.1 does not compress headers. (HTTP/2 compresses the headers and data to the binary format.)
- Only accept request response patterns.(HTTP/2 support server push. That means the client can send multiple messages from one request to the server. - streaming) - Less chatter EX:- In HTTP/1.1 Clients have to send 3 requests to access 3 assets and have to get three responses from that request. In
- HTTP/2 clients can send requests inside one TCP connection and wait for one response from the server.
- HTTP/2 supports multiplexing ( Server and client send multiple messages in parallel over the same TCP connection.)
It uses Protocol Buffers (Protobuf) for service-to-service communication.
Messages are smaller than JSON.
Passing JSON is more CPU intensive. (Because the format is human readable.)
Protobuf provides more security than JSON because it’s not human readable, easy to install SSL for client and server.
Benefits
- Provide 30-40% more performance when compared to REST because of HTTP/2 protocol.
- gRPC uses binary serialization, which also provides higher Performance and less bandwidth compared to JSON.
- Support multiple languages and platforms.
- Support for bi-directional streaming.
- Support SSL/TLS usage.
- Support many authentication methods.
Usages
- Synchronous microservice to microservice communication. Polyglot environments that need to support mixed programming languages.
- Low latency and high throughput communication where performance is critical.
- Point-to-point real-time communication. (push messages in real-time and are required to support bi-directional streaming.)
- The network-constrained environment requires less bandwidth usage. (Binary gRPC messages are always smaller than text-based JSON)

4. WebSocket (ws:// , wss://)

A websocket uses for real-time two way communications between client and server. (Ex:- chat with an agent.)
Send messages to the server and receive event based communication without having polling.
Provide bidirectional protocol for same client server communications.
Stateful protocol - Until terminating the connection from one party, communication stays alive.
Use Cases
- For real-time application development. (Stock market/ Crypto currency prices changing)
- Online gaming applications
- Chat applications

5. Webhooks

For the simple understand, a webhook is just a POST request that is used to push messages/events between two services.
Uses HTTP protocol to communicate with applications.
Usages
- Get real-time notifications/data from external services.
- To trigger scheduled actions.
- Sync data between different systems.
Benefits
- Best way to get real-time updates.
- Easy to integrate with an application.
- Efficient and reduce the latency.
Drawback
- Issue with delivery reliability
- Security issue (Can be affect to DDOS easily)

So, through this article, I have discussed what the microservice communication methods are and what the synchronous communication patterns are. If you have any questions regarding this article please let me know by commenting. I will hope to discuss synchronous communication more deeply in the upcoming articles. So stay tuned with me.

Why are API gateways so damn important?🤔

Kav — Wed, 22 Nov 2023 17:27:52 +0000

You may heard about "API Gateway" term somewhere in your software engineering journey.
You probably should've Googled and learned that back then, or probably not. I guess that concept was kinda tricky for you, even though it's pretty basic.
Hope this article helps you pick up some new knowledge or brush up on what you already know. Let's dive into this 🙌.

What the heck is this API gateway thing?

Okay, calm down. If you are total noob here, just forget the word "API" for now. You all know what is a gate, yeah? Think of this whole API gateway situation as your old gate.

What does this gate actually do? It's like the entry point to your property, and separates your stuff from everybody else's, yeah?
That's what these API gateway things are doing too. It acts as a single entry point to all the APIs. It uses to separate client APIs from internal services(microservices).

What's the point of using these API gateways anyway?

1. Handling cross-cutting concerns.
Let me take a guess, you have no idea what this "cross-cutting concerns" means, yeah? Just think of it as like the common stuff that every API endpoint needs, like authentication, authorization, rate limiting, caching etc...
Let me explain what are the benefits of using API gateway for cross cutting concerns.

Reduce the duplications - Let's use authorization as an example. If we don't have an API gateway, we need to duplicate the authorization implementation in every microservice. And that means a bunch of duplicate codes.
Reduce the inconsistent implementations - Different engineering teams may work on each (different) microservice and their implementations differently from each other. With an API gateway though, we can reduce that mess.
Reduce the code complexity - So having less duplicate code and keeping things consistent makes the overall code way easier to understand.

2. Decouples the client applications from the internal microservices.
Microservice architectures consist with set of little services. Without an API gateway, we would need to call each service directly. So if anything changes, we have to change the client app code too.

For an example, let's assume we deploy our application on AWS Beanstalk or EC2. If we move the app to another Beanstalk or EC2, we would need to update the client endpoint too.

But with an API gateway, we don't need to mess with the client code. It just maps the external APIs to the new internal services.

3. Aggregate data from different services to a single response.
I think you got the idea. Let's imagine a client requests some data from the server. They would typically need to navigate multiple microservices to gather the full data required (You can think this as something like database query concept). In these types of situations, an API gateway can aggregate the necessary information from the various services, and deliver it to the client as a single response.

4. Request sharping.
Okay, what is this request sharping doing? It helps to optimize backend performance by managing amount of requests received. We can take some examples like rate limiting, caching, queueing for this. (we will discuss more about these features in our future articles.)

API gateway patterns.

I'm going to discuss about 3 most popular gateway patterns in briefly through this article. We will be discussing more details about these patterns in our upcoming articles and projects.

1. Gateway Routing Pattern.
Gateway routing pattern routes incoming API requests to the relevant microservice.

2. Gateway Aggregation Pattern.
API gateway aggregate data from multiple microservices into single response.

3. Gateway Offloading Pattern.
API gateway handle cross cutting concerns before passing the requests to the relevant microservice.

Alright, at this point I’d like to explore some useful applications of API gateways.

1. Backend for Frontend Pattern.
Here we use separate API gateways for specific client applications.

For an example, One API gateway for web client, another API gateway for mobile client so on.

2. Service Aggregator Pattern.
Here what this does, when API gateway receives requests from the clients, dispatch the request of multiple internal backend services, combine the results and responds back to the client.

3. Service Registry and Discovery Pattern.
This allows to find the network locations of microservices without injecting or coupling. Service registry uses to update service locations. Using service discovery pattern, client find network locations of relevant microservices.

That covers the main points of API gateway I wanted to share through this article. If you're new to these concepts, hopefully this article has helped sharp your knowledge. Feel free to drop any questions in the comments. Look forward to connecting again in a future article with you all!