Knowledge Factory

The image illustrates an orchestration-based saga pattern for handling distributed transactions across two microservices: Order Service and Customer Service . This approach uses a central orchestrator (the saga) to coordinate the interactions between services and ensure consistency. Here’s an end-to-end explanation of the flow: 1. Order Creation Request A client sends an HTTP POST /orders request to the Order Controller in the Order Service . The Order Controller is responsible for receiving the request and delegating it to the Order Service . 2. Order Creation in the Saga The Order Service invokes the create() method in the Create Order Saga . The Create Order Saga is the orchestrator responsible for coordinating the steps involved in completing the transaction. 3. Order Aggregate Creation The Create Order Saga initiates the creation of the Order aggregate in the Order Service . The Order aggregate represents the state and business logic of the order. 4. Reserve Credit Com...

Choreography-Based Saga Architecture: Here's a detailed walkthrough: Steps in the Saga Step 1: Initiating the Saga (POST /orders) A client sends a  POST  request to the  Order Service  to create an order. The  Order Service  processes this request, creates an  Order  entity (aggregate), and publishes an  Order Created  event to the  Order Events Channel . Step 2: Order Created Event The  Order Created  event flows through the  Order Events Channel  to notify interested services (e.g.,  Customer Service ) about the creation of the order. The event contains details about the order, such as its ID, total amount, and customer ID. Step 3: Reserve Credit (POST /customer) The  Customer Service  receives the  Order Created  event and attempts to reserve the required credit for the order. If the credit limit is sufficient: It updates the  Customer  entity (aggregate) to reserve the credi...

Choreography-Based Saga Architecture: Here's a detailed walkthrough: Steps in the Saga Step 1: Initiating the Saga (POST /orders) A client sends a POST request to the Order Service to create an order. The Order Service processes this request, creates an Order entity (aggregate), and publishes an Order Created event to the Order Events Channel . Step 2: Order Created Event The Order Created event flows through the Order Events Channel to notify interested services (e.g., Customer Service ) about the creation of the order. The event contains details about the order, such as its ID, total amount, and customer ID. Step 3: Reserve Credit (POST /customer) The Customer Service receives the Order Created event and attempts to reserve the required credit for the order. If the credit limit is sufficient: It updates the Customer entity (aggregate) to reserve the credit. It publishes a Credit Reserved event on the Customer Events Channel . Step 4: Insufficient Credit If the customer...

Architecture diagram: Components Breakdown: Microservices 1, 2, and 3: These are the core applications responsible for generating logs. Logstash: Acts as a central log processor. It collects logs from the microservices, transforms them into a common format (usually JSON), and sends them to Elasticsearch. Elasticsearch: A powerful search engine that stores and indexes the logs received from Logstash. It allows for fast retrieval and analysis of log data. Kafka: A distributed streaming platform used to buffer and distribute logs from the microservices to Logstash. Kafka ensures reliability and fault tolerance in log handling. Redis: An in-memory data store used for caching, session management, and other purposes. Redis can help improve the performance and scalability of the application. Beats: A lightweight data shipper that can forward logs from the microservices to Logstash or Kafka. Beats is typically used for collecting logs from application files or other sources. Kibana: A data vis...