Chapter 2, Communication Patterns Flashcards
What is synchronous communication in microservices?
In synchronous communication, one microservice invokes another microservice and expects a response within a given time frame. Patterns used include Request-Response and Remote Procedure Calls (RPC).
Page 48
How do microservices communicate asynchronously?
In asynchronous communication, microservices communicate by passing messages asynchronously with the help of an intermediary (known as a message broker), using patterns such as queue-based messaging and publisher-subscriber messaging.
Page 48
Which communication pattern is most commonly used in cloud native applications?
The Request-Response pattern is probably the most commonly used communication pattern in cloud native applications and distributed computing at large.
Page 49
How does the Request-Response pattern work in cloud native applications?
The Request-Response pattern establishes a connection between the client and the server application (microservice) to exchange data synchronously. The client sends a request for data and waits for a response or until a time-out occurs. This style is sometimes referred to as query-based interaction.
Page 50
Why is the Request-Response pattern popular for building cloud native applications?
It is often used for building interactive business logic that requires immediate responses and is agnostic of underlying network protocols and data formats. HTTP and RESTful services are common realizations of this pattern.
Page 50
What is RPC and when is it recommended?
RPC is an efficient and robust way to build synchronous communication among microservices. Cloud native RPC technologies such as gRPC are recommended, but RPC may not be the best choice for services exposed to external consumers like web and mobile applications.
Page 56
How does asynchronous communication work among microservices?
One microservice sends data as messages without expecting a response. Communication is facilitated by a message broker, which receives messages from the producer and sends them to the consumer.
Page 58
What is the Multiple-Receiver or Publisher-Subscriber pattern in asynchronous messaging?
This pattern is used when the same message needs to be sent to multiple consumers interested in a particular event. It is often used in cloud native applications for microservices that need to execute business logic or notify other services upon certain events.
Page 63
What is the role of the event bus in the Publisher-Subscriber pattern?
The event bus handles publisher and subscription requests and delivers messages to corresponding subscribers.
Page 64
What is the Asynchronous Request-Reply pattern?
This pattern is used when producers need to send messages to a consumer via a broker and receive a reply from the consumer via the broker on a different channel.
Page 66
How is the Asynchronous Request-Reply pattern used in practice?
It is not an alternative to the Request-Response pattern but serves a specific purpose when a reply containing business data is needed. Messaging solutions like RabbitMQ, ActiveMQ, and Azure Service Bus support this pattern.
Page 67
What should be considered when using the Asynchronous Request-Reply pattern?
Although it might seem more reliable than synchronous messaging, the performance implications due to using queues and correlating messages must be considered. This pattern is less frequently used than other asynchronous patterns.
Page 68
What is a key aspect of building communication among cloud native applications?
One of the most important aspects is the service definition, which defines the microservice interface to its consumers and can differ based on the communication protocol used.
Page 69
How are service definitions used in synchronous communication?
Service definitions are published to a central service registry, a metadata repository that other microservices and developers can interact with. The registry should handle various service definitions such as OpenAPI, gRPC, and GraphQL schemas.
Page 70
How does having a service definition impact the microservice development life cycle?
It changes the development life cycle as you can code-generate or validate the microservice implementation against the service definition, ensuring compliance with the advertised definition.
Page 72
How are service definition patterns related to other patterns?
They are closely related to the Service Registry and Discovery pattern, the synchronous Request-Response and RPC patterns, and the API management patterns.
Page 73
How are service definitions used in asynchronous communication?
Messages exchanged between producers and consumers contain structured data serialized/deserialized using a schema defining the data. Producers and consumers use a central metadata registry to store these schemas.
Page 73
Why are schemas important in asynchronous messaging?
Schemas ensure reliable communication by validating data exchanged between producers and consumers, avoiding inconsistencies and data mismatches.
Page 77
What is the WebSocket protocol and how is it used?
WebSocket is a technology for implementing synchronous Request-Response patterns, supporting full duplex and asynchronous messaging. It uses a single TCP connection for bidirectional traffic and an initial HTTP handshake.
Page 83
How does the Request-Response Pattern work?
In the Request-Response pattern (Figure 2-1), one microservice (which acts as the client) sends a request and waits for a response from one or more other microservices or systems. The business logic of the client application blocks until it receives the response, and the communication channel has to be kept open until the response is received by the client application.
49
How does the Single-Receiver Pattern work?
The Single-Receiver pattern is built by publishing messages to a queue in the message broker. One consumer service or system then consumes messages from that queue. The producer service is interested only in whether the message is delivered successfully to the queue; it doesn’t care when or whether the message is processed.
60
How does the Multiple-Receiver Pattern work?
In the Multiple-Receiver pattern, messages are delivered to more than one consumer microservice. We also use a message broker or an event bus to facilitate the asynchronous message delivery. One microservice publishes a message to a topic in the event bus, and one or more microservices can subscribe to a given topic. The message is asynchronously delivered to all the subscribers of that topic.
The Multiple-Receiver pattern is implemented using an event bus (Figure 2-5)
The event bus is responsible for handling the publisher and subscription requests and delivering the message to the corresponding subscribers.
63
How does Asynchronous Request-Reply Pattern work?
In the Asynchronous Request-Reply pattern, we follow the same messaging model used in the Single-Receiver pattern: the producer microservice publishes messages to a queue in a message broker, and then the producer consumes that message from the queue. However, the message contains metadata specifying that it requires a reply, the location where the reply should be sent, and how to correlate the reply. The producer uses that information to send the reply back to the producer via a completely different channel established through a separate queue in the message broker.
66
How does The service definition work?
The service definition is a way of declaring how a given service can be consumed by consumers/clients. It is something that will be shared with consumers prior to establishing the communication channel among the services where synchronous communication takes place.
As illustrated in Figure 2-7, microservices can publish their service definitions to a service registry (or they can be published manually by the microservice owners). Then the consumers of those microservices can connect to the service registry and obtain the service definitions (programmatically or manually by the developers). This step is known as service discovery.
70
