24
loading...
Interprocess Communication in Microservices
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 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 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.
Find out more details about REST constraints here.
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 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
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 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.
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
24