There are lots of different technologies available to choose from that can be used to communicate between your microservices. In this blog post, I will explain a few important ways that can be used to communicate between microservices.
The communication between microservices can be one of the following two ways.
Synchronous Communication
Synchronous Communication is real-time communication between two services. The caller service will wait until it gets the response from the invoked service within the configured timeout threshold.
Services can use synchronous request/response-based HTTP communication mechanisms, such as
- REST
- gRPC
REST
REST is an acronym for REpresentational State Transfer. It is an architectural style for distributed hypermedia systems and was first presented by Roy Fielding in 2000.
REST also does have it's own 6 guiding constraints which must be satisfied if an interface needs to be referred to as RESTful.
- 1. Uniform interface - A resource in the system should have only one logical URI, and that should provide a way to fetch related or additional data.
- *2. Client-server * - This constraint essentially means that client application and server application MUST be able to evolve separately without any dependency on each other. A client should know only resource URIs, and that’s all.
- 3. Stateless - Make all client-server interactions stateless. The server will not store anything about the latest HTTP request the client made. It will treat every request as new. No session, no history.
- 4. Cacheable - In REST, caching shall be applied to resources when applicable, and then these resources MUST declare themselves cacheable. Caching can be implemented on the server or client-side
- 5. Layered system - REST allows you to use a layered system architecture where you deploy the APIs on server A, and store data on server B and authenticate requests in Server C, for example. A client cannot ordinarily tell whether it is connected directly to the end server or an intermediary along the way.
- 6. Code on demand (optional) - Most of the time, you will be sending the static representations of resources in the form of XML or JSON. But when you need to, you are free to return executable code. e.g., clients may call your API to get a UI widget rendering code. It is permitted.
Find out more details about REST constraints here.
gRPC
gRPC is a modern, open-source, high-performance remote procedure call (RPC) framework that can run anywhere. gRPC enables client and server applications to communicate transparently and simplifies the building of connected systems. It was initially developed at Google in 2015 as the next generation of the RPC infrastructure Stubby.
In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services.
On the server-side, the server implements this interface and runs a gRPC server to handle client calls. On the client-side, the client has a stub (referred to as just a client in some languages) that provides the same methods as the server.
By default, gRPC uses Protocol Buffers, Google’s mature open source mechanism for serializing structured data (although it can be used with other data formats such as JSON).
Find out more details about gRPC here.
Asynchronous Communication
Asynchronous Communication is when you send a message without expecting an immediate response from the invoked service. The caller service will just send the request and invoked service will queue the request and process it.
Services can use asynchronous, message-based communication mechanisms such as
- Message Queues
- Pub/Sub
Message Queues
A message queue is an architecture that provides asynchronous communication, allowing microservices to interact with each other without coupling. These messages are then stored (in memory or persisted) in a queue and processed by another microservice (called the Consumer).
Below are the few popular Messaging Queues that can be used for your application.
Pub/Sub
Pub/Sub enables you to create systems of event producers and consumers, called publishers and subscribers. Publishers communicate with subscribers asynchronously by broadcasting events, rather than by synchronous calls.
Publishers send events to the Pub/Sub service, without regard to how or when these events will be processed. Pub/Sub then delivers events to all services that need to react to them.
Compared to synchronous communication through REST or RPCs, where publishers must wait for subscribers to receive the data, such asynchronous integration increases the flexibility and robustness of the system overall.
Below are the few popular pub/sub services that can be used for your application.
References:
- https://restfulapi.net/rest-architectural-constraints/
- https://grpc.io/docs/what-is-grpc/introduction/
Thank you for reading
Hope you find these resources useful. If you like what you read and want to see more about system design, microservices, and other technology-related stuff... You can follow me on
- Twitter - Follow @vishnuchi
- Subscribe to my weekly newsletter here.
Top comments (0)