L-3: Sync vs Async Communication in Microservices: REST APIs vs RabbitMQ/Kafka

Microservices Communication: Synchronous and Asynchronous Methods

Introduction to Microservices Communication

• The lecture begins with a welcome message and an introduction to the topic of microservices communication, emphasizing the importance of understanding how services interact.

Types of Communication Between Services

• There are two primary methods for services to communicate: synchronous and asynchronous communication. A hybrid approach that combines both is also possible.

Understanding Synchronous Communication

• Synchronous communication requires one service to wait for a response from another before proceeding. This method is distinct from JavaScript's synchronous model.

• In synchronous communication, when a user sends a request to Service B, Service A must wait for Service B's response before continuing its process.

Visualizing Synchronous Interaction

• A diagram illustrates that Service A sends a request to Service B and waits for the response, highlighting the blocking nature of this interaction.

Exploring Asynchronous Communication

• Asynchronous communication allows clients to make requests without waiting for immediate responses. REST APIs are commonly used in this context.

Event Bus in Asynchronous Systems

• An event bus (or event broker) facilitates communication between services by emitting events based on user actions, such as registration or login processes.

User Registration Process Example

• When a user registers through the service, their information is stored in a database while simultaneously emitting an event indicating that a new user has been created.

Handling Events in Services

• The emitted event contains details about the newly created user, which can be processed by other services listening for such events (e.g., storing additional user information).

Importance of User Information in Services

• For effective operation, services like S4 require access to both user information and product details related to orders made by users.

Product Purchase Process Overview

• The purchase service records transactions in its database while also emitting relevant events that other services can listen for and act upon accordingly.

Product Purchase Event Handling

Overview of Product Purchase Process

• The product purchase process involves listening for events related to product purchases, which triggers an immediate event emission upon the creation of a purchase.

• This event captures all relevant information about the purchased product and associates it with the user making the purchase.

Implementation Challenges

• The current implementation method is not ideal; if a service fails, user information may become inaccessible.

• While this approach serves as a basic understanding, practical coding will clarify these concepts further.

Service Architecture

• Different services are involved: User Service, Product Service, and Purchase Product Service. An Order Service needs to be built to handle orders by users.

• An event bus pattern is introduced where each service maintains its own database for better data management.

Database Structure

• Each service has its own database (DB), ensuring that data remains organized and accessible across different services.

• When a request is made from the client side, it creates a user and emits an event indicating that a user has been created.

Event Listening Mechanism

• Events emitted include types such as "User Created" or "Product Purchased," allowing listeners to identify which type of event they are handling.

• Upon receiving an order-related event, user information is stored in the respective database table associated with users.

Data Flow During Purchases

• When a product is created, it gets saved in its dedicated database before emitting an event regarding its creation.

• If a product is purchased by a user, this action triggers another event that allows tracking which products were bought by which users.

User Interface Interaction

Database Communication Methods

Benefits and Drawbacks of the Database Method

• The discussed database method has several benefits, but it also comes with drawbacks. One major drawback is the need to use an additional database, which increases costs.

Synchronous vs Asynchronous Communication

• Synchronous communication can be achieved through REST APIs, while asynchronous communication can utilize message brokers like RabbitMQ or Kafka.

• REST API methods are generally easier to understand compared to message broker methods, which may be more complex.

Real-Life Examples of Communication Types

• In synchronous communication, a service waits for a response before proceeding. This can lead to delays in processing requests until responses are received.

• A real-life example is ordering food through an app like Zomato. When an order is placed, the UI provides immediate feedback that the order is being processed.

Event Handling in Asynchronous Systems

• Upon placing an order (e.g., pizza), the event type (order) is stored in a queue data structure that follows a first-in-first-out principle.

• Multiple events can be queued; once one event is resolved, the next will be processed sequentially.

Non-blocking Operations in Applications

• While waiting for an order to be fulfilled (like making and delivering pizza), users can continue interacting with other features of the application without blocking their experience.