Guided Compound Exercise - CQRS Pattern with other Design Patterns - Microservice Design Patterns - Online Retail System

[akash-coded]

In this exercise, we will incorporate event-driven architecture using Spring Kafka and demonstrate the use of the Circuit Breaker pattern with Resilience4j. We'll build a microservices-based system that demonstrates the practical application of CQRS, complete with commands, queries, event sourcing, and sagas.

Scenario: Online Retail System

Overview

Build an Online Retail System comprising several microservices. This system will handle product management, order processing, and customer interactions. The CQRS pattern will be applied to separate read (query) and write (command) responsibilities.

System Components

1. Product Service (Command Side): Manages product catalog including adding and updating products.
2. Order Service (Command Side): Handles order creation and updates.
3. Customer Service (Query Side): Manages customer information and queries.
4. Reporting Service (Query Side): Generates reports and handles complex queries.
5. Event Store: A service to store events resulting from commands.
6. Kafka Broker: To handle event messages between services.

Exercise Objectives

1. Implement Core Microservices: Each microservice should have its own database. Use JPA and H2 for data persistence.
2. Apply CQRS Pattern: Implement command and query responsibilities separately in the services.
3. Event-Driven Architecture: Use Spring Kafka to propagate events between services.
4. Implement Sagas for Complex Transactions: Use sagas for handling distributed transactions that span multiple services.
5. Circuit Breaker with Resilience4j: Implement circuit breakers in service communication to enhance system resilience.

Code Repository Structure

OnlineRetailSystem/
├── ProductService/
├── OrderService/
├── CustomerService/
├── ReportingService/
├── EventStore/
└── Kafka/

Detailed Steps & Implementations

Step 1: Setup Microservices with Spring Boot

• Initialize each microservice with Spring Initializr including necessary dependencies (Spring Web, JPA, Kafka, H2, Resilience4j).
• Configure application.properties for each service with appropriate database and Kafka settings.

Step 2: Implement Command and Query Models

• Product and Order Services: Implement command models to handle create and update operations.
• Customer and Reporting Services: Implement query models optimized for read operations.

Step 3: Kafka Integration for Event-Driven Communication

• Configure Kafka producer in command services to publish events after a command is executed.
• Configure Kafka consumer in query services and event store to react to these events.

  @KafkaListener(topics = "productEvents", groupId = "retail-group")
  public void listenProductEvents(String message) {
      // Handle event
  }

Step 4: Implement Event Store

• Create a service or use a database to store all events. This acts as the source of truth for the system state.
• Events should be immutable and timestamped.

Step 5: Implement Sagas for Distributed Transactions

• Use Spring Kafka to manage saga steps. For example, an order creation might involve steps handled by different services.
• Implement compensation actions to handle failures in sagas.

Step 6: Circuit Breaker Implementation

• Use Resilience4j to wrap inter-service calls in circuit breakers. This is crucial for maintaining system stability.

  @CircuitBreaker(name = "customerService", fallbackMethod = "fallbackMethod")
  public Customer getCustomerDetails(Long customerId) {
      // RestTemplate or FeignClient call to Customer Service
  }

Step 7: Testing and Observations

• Write integration tests to simulate scenarios like service failure, event processing, and saga completions.
• Observe how the system behaves and recovers from failures.

Step 8: Monitoring and Actuator Integration

• Use Spring Boot Actuator to monitor the health of each microservice.
• Optionally integrate with Prometheus and Grafana for advanced monitoring.

Configurations and Properties

• Spring Kafka Configuration: Configure bootstrap-servers, consumer-group-id, topics, etc.
• Database Configuration: Each microservice should have its own H2 database configuration.
• Resilience4j Configuration: Define circuit breaker instances and their parameters in application.yml.

Additional Guidelines

• Documentation: Use Swagger or Spring Rest Docs to document API endpoints.
• Error Handling: Implement global exception handling for clean error responses.
• Version Control: Use Git for version control, creating branches for each major feature.

Conclusion

This exercise provides a hands-on experience with the CQRS pattern in a microservices environment, highlighting its benefits in separating command and query responsibilities and enhancing system scalability and maintainability. By incorporating event-driven architecture, sagas, and circuit breakers, the exercise also demonstrates the resilience and robustness of the system in handling complex, distributed transactions and failures.

---

We'll emphasize the implementation of design patterns, workflow, event flow, and compensating transactions, with a strong focus on CQRS.

1. ProductService (Command Side)

Responsibilities:

• Adding new products.
• Updating existing product details.

Implementation Details:

• Command Model: Define commands like CreateProductCommand and UpdateProductCommand.
• Event Publishing: After executing a command, publish an event (e.g., ProductCreatedEvent, ProductUpdatedEvent) to Kafka.
• Data Persistence: Use JPA repositories to persist product data in the H2 database.

@Service
public class ProductService {
    // Inject dependencies like ProductRepository and KafkaTemplate

    public Product createProduct(CreateProductCommand command) {
        // Logic to create a product
        kafkaTemplate.send("productEvents", new ProductCreatedEvent(/* ... */));
        return product;
    }

    // Similar implementation for updateProduct
}

2. OrderService (Command Side)

Responsibilities:

• Handling order creation and updates.

Implementation Details:

• Command Model: Implement commands like CreateOrderCommand.
• Event Publishing: Publish events such as OrderCreatedEvent to Kafka.
• Sagas for Distributed Transactions: Implement a saga to coordinate complex operations involving multiple services.

@Service
public class OrderService {
    // Implementation details for order creation and update
    // Including saga initiation and steps
}

3. CustomerService (Query Side)

Responsibilities:

• Managing customer information queries.

Implementation Details:

• Query Model: Create DTOs and services optimized for read operations.
• Event Consumption: Listen to relevant events (e.g., OrderCreatedEvent) and update the query model accordingly.

@Service
public class CustomerQueryService {
    @KafkaListener(topics = "orderEvents")
    public void onOrderCreated(String message) {
        // Logic to update the query model based on the order event
    }
}

4. ReportingService (Query Side)

Responsibilities:

• Generating reports and handling complex queries.

Implementation Details:

• Query Model: Design models optimized for reporting needs.
• Event Consumption: Consume events to keep the reporting data up-to-date.

5. EventStore

Responsibilities:

• Storing all events as a source of truth.

Implementation Details:

• Event Persistence: Store all incoming events in a database.
• Immutability: Ensure that stored events are immutable and timestamped.

CQRS Implementation Details

• Command and Query Separation: Implement command-handling logic in ProductService and OrderService. Implement query-handling logic in CustomerService and ReportingService. This separation ensures that the system is optimized for both write and read operations.
• Event-Driven Architecture: Use Kafka to facilitate communication between services. Events are produced by command services and consumed by query services to update their respective models.
• Sagas and Compensating Transactions: In scenarios where a business transaction spans multiple microservices, use sagas to manage the distributed transaction. If a step in the saga fails, implement compensating transactions to revert the overall process to a consistent state.

Workflow and Event Flow

1. Command Execution: A command is executed in a command service (e.g., creating an order).
2. Event Publishing: The command service publishes an event to Kafka.
3. Event Consumption: The event is consumed by query services and the event store.
4. Model Update: Query services update their models based on the event data.
5. Saga Continuation/Compensation: If involved in a saga, the next step is executed, or a compensating transaction is initiated in case of failures.

---

Continuing with the implementation details of the CQRS pattern in a microservices environment using Spring Boot:

6. Implementing Kafka for Event-Driven Communication

Responsibilities:

• Facilitating asynchronous communication between microservices.
• Ensuring reliable delivery of events.

Implementation Details:

• Kafka Producer: In command services (ProductService, OrderService), implement Kafka producers to publish events.
• Kafka Consumer: In query services (CustomerService, ReportingService), implement Kafka consumers to listen and react to relevant events.
• Kafka Configuration: Configure Kafka topics, consumer groups, and error handling strategies.

@Configuration
public class KafkaProducerConfig {
    // Kafka producer configuration
}

@Configuration
public class KafkaConsumerConfig {
    // Kafka consumer configuration
}

7. Integrating Resilience4j for Circuit Breaking

Responsibilities:

• Providing fault tolerance in microservices communication.
• Preventing cascading failures in the system.

Implementation Details:

• Circuit Breaker Configuration: Define circuit breaker instances and their thresholds in application properties.
• Circuit Breaker Annotation: Use the @CircuitBreaker annotation in services where inter-service calls are made.

@Service
public class ExternalServiceCaller {
    @CircuitBreaker(name = "externalService", fallbackMethod = "fallback")
    public String callExternalService() {
        // RestTemplate or FeignClient call
    }

    public String fallback(Throwable t) {
        // Fallback logic
    }
}

Additional Considerations for CQRS Implementation

Event Store and Event Sourcing

Incorporate event sourcing to capture the state changes of your system as a sequence of events. This not only acts as a source of truth but also allows for replaying events to rebuild the system state or support new features.

Query Service Optimization

Optimize query services for read operations. This might involve creating specialized data structures or databases that are designed for fast and efficient reads, tailored to the specific query patterns of your application.

Handling Consistency

CQRS and event-driven architecture can lead to eventual consistency. Ensure your design accommodates this and implement strategies to handle data synchronization between command and query databases.

Saga Orchestration

In complex business processes that span multiple microservices, orchestrate sagas to manage distributed transactions. Implement each step of the saga and define compensating transactions to maintain data consistency in case of partial failures.

Conclusion

This comprehensive exercise provides a deep dive into implementing the CQRS pattern in a microservices architecture. It emphasizes the importance of clear separation between command and query models, the role of event-driven communication in ensuring system consistency, and the need for fault tolerance using patterns like circuit breakers.

[akash-coded]

Workflow and Scenario Implementation Guidelines

Let's refine the exercise to include a more detailed explanation of the flow of events, the purpose and functionalities of the app and its individual microservices, and the advantages offered by implementing CQRS and other patterns. We'll create a comprehensive view of the end-to-end workflow within the Online Retail System.

Exercise Overview: Online Retail System

Purpose and Functionalities

The Online Retail System is designed to manage an e-commerce platform, handling products, orders, and customer interactions.

1. Product Service (Command Side):

   • Purpose: Manages the product catalog. It handles adding new products and updating existing products.
   • Functionalities: Create, update product details; publish events about these changes.

2. Order Service (Command Side):

   • Purpose: Processes customer orders.
   • Functionalities: Place new orders, update order status; publish events about order changes.

3. Customer Service (Query Side):

   • Purpose: Provides a view for customer information and their order history.
   • Functionalities: Aggregate and display customer and order data.

4. Reporting Service (Query Side):

   • Purpose: Generates reports and analytics for business insights.
   • Functionalities: Aggregate data for reporting, handle complex queries.

5. Event Store:

   • Purpose: Acts as a centralized store for all events emitted by command services.
   • Functionalities: Store and manage event data.

6. Kafka Broker:

   • Purpose: Facilitates communication between services using an event-driven architecture.
   • Functionalities: Transmit events between services, handle message queuing and delivery.

Workflow and Event Flow

1. Command Side Operations:

   • In ProductService or OrderService, a command (e.g., create/update product, place order) is executed.
   • Upon successful command execution, an event (e.g., ProductCreated, OrderPlaced) is published to Kafka.

2. Event Store Update:

   • All events are consumed by the Event Store and stored for historical tracking and potential event replay.

3. Query Side Update:

   • CustomerService and ReportingService listen to relevant events.
   • These services update their query models based on received events, ensuring they have the latest data.

4. Read Operations:

   • CustomerService provides updated customer and order information.
   • ReportingService offers insights and reports based on the latest data.

Implementing CQRS and Event-Driven Architecture

1. Product and Order Services:

   • Implement command handlers for create/update operations.
   • Use Kafka templates to publish events to Kafka topics.

2. Customer and Reporting Services:

   • Implement Kafka listeners to consume events.
   • Update query models based on event data to reflect the current state of the system.

3. Implementing Sagas:

   • Coordinate complex transactions across microservices.
   • Define compensation actions for each step of the saga to revert changes in case of failure.

---

Let's delve into specific events, actions, and scenarios for the Online Retail System. We will cover event production and consumption, compensating transactions for sagas, and circuit breaker scenarios.

Detailed Event Flow and Actions

ProductService (Command Side)

• Events Produced: ProductCreated, ProductUpdated.
• Actions:
  • On creating a new product, publish a ProductCreated event.
  • On updating a product, publish a ProductUpdated event.

OrderService (Command Side)

• Events Produced: OrderPlaced, OrderUpdated.
• Actions:
  • On placing an order, publish an OrderPlaced event.
  • On updating an order status, publish an OrderUpdated event.

CustomerService (Query Side)

• Events Consumed: OrderPlaced, OrderUpdated.
• Actions:
  • On receiving OrderPlaced, update the customer's order history.
  • On receiving OrderUpdated, refresh the customer's current order status.

ReportingService (Query Side)

• Events Consumed: ProductCreated, ProductUpdated, OrderPlaced, OrderUpdated.
• Actions:
  • Aggregate data from product and order events for reporting.
  • Generate insights based on the latest state of products and orders.

Implementing Compensating Transactions for Sagas

Scenario 1: Order Cancellation

• Trigger: A customer cancels an order which is already processed.
• Saga Steps:
  1. OrderService starts the saga by marking the order as canceled.
  2. ProductService is informed to update the inventory (restock the product).
  3. CustomerService updates the customer’s order history.
• Compensating Transaction:
  • If restocking fails, OrderService is informed to revert the order cancellation.

Scenario 2: Failed Payment Processing

• Trigger: An order is placed, but payment processing fails.
• Saga Steps:
  1. OrderService initiates order placement.
  2. Payment Service (external) processes the payment.
  3. OrderService finalizes the order based on payment success.
• Compensating Transaction:
  • If payment fails, send a rollback event to OrderService to cancel the order.

Scenarios to Implement (Workflows)

Scenario 1: Reporting Service Overload

• Trigger: High demand for complex reports causes ReportingService to slow down.
• Circuit Breaker Implementation: CustomerService implements a circuit breaker for requests to ReportingService.
• Action on Circuit Breaker Trip: Provide cached reports or a message indicating delayed report availability.

Scenario 2: External Payment Service Unavailability

• Trigger: The external payment service is temporarily unavailable during order processing.
• Circuit Breaker Implementation: OrderService wraps payment processing calls with a circuit breaker.
• Action on Circuit Breaker Trip: Queue the order and attempt the payment process later when the service is available.

Continuing with more detailed scenarios, let's explore additional aspects of implementing CQRS, event-driven architecture, sagas, and circuit breakers in the context of the Online Retail System.

Additional Detailed Scenarios

Scenario 3: Inventory Management Failure

• Trigger: A new order is placed, but the ProductService fails to update inventory due to a database issue.
• Saga Steps:
  1. OrderService receives and processes a new order.
  2. ProductService attempts to update inventory but encounters a failure.
  3. OrderService is notified of the failure.
• Compensating Transaction:
  • OrderService compensates by canceling the order and notifying the customer of the issue.
• Circuit Breaker Implementation: Wrap inventory update calls in ProductService with a circuit breaker.
• Action on Circuit Breaker Trip: Queue the inventory update and retry when the service is stable.

Scenario 4: Customer Service Timeout

• Trigger: High load causes response delays in CustomerService.
• Circuit Breaker Implementation: Services querying CustomerService (like OrderService) use a circuit breaker.
• Action on Circuit Breaker Trip: Provide a default response, possibly using cached data, and log the incident for later investigation.

Scenario 5: Payment Saga with External Service Failure

• Trigger: An order is placed, but an external shipping service fails.
• Saga Steps:
  1. OrderService confirms order placement.
  2. External Shipping Service is called to dispatch the order but fails.
  3. OrderService is notified of the failure.
• Compensating Transaction:
  • OrderService reverts the order status and issues a refund if payment was processed.

Continuing with additional detailed scenarios, we'll focus on the intricacies of the CQRS pattern on both the command and query sides, and how the event store plays a pivotal role in the system.

Scenario 6: Product Return Process

• Command Side (OrderService):
  • Trigger: A customer initiates a return for a delivered product.
  • Action: OrderService processes the return request and publishes an OrderReturned event.
  • Event Store Involvement: The OrderReturned event is stored, capturing the state change.
• Query Side (CustomerService, ReportingService):
  • CustomerService listens to OrderReturned events to update the customer’s order history.
  • ReportingService aggregates data from OrderReturned events for analytics on product returns.

Scenario 7: Updating Customer Preferences

• Command Side (CustomerService):
  • Trigger: A customer updates their communication preferences.
  • Action: CustomerService updates the customer profile and publishes a CustomerPreferencesUpdated event.
  • Event Store Involvement: The CustomerPreferencesUpdated event is stored, reflecting the update.
• Query Side (MarketingService - Hypothetical):
  • MarketingService (a potential query-side service) uses this information to tailor marketing communications to customer preferences.

Scenario 8: Bulk Product Update

• Command Side (ProductService):
  • Trigger: An administrative batch process updates prices for a range of products.
  • Action: ProductService handles the bulk update and publishes ProductPriceUpdated events for each product.
  • Event Store Involvement: Each ProductPriceUpdated event is stored, documenting the price changes.
• Query Side (ReportingService):
  • ReportingService consumes these events to adjust pricing data in its reporting models.

Scenario 9: Real-time Stock Level Display

• Command Side (InventoryService - Hypothetical):
  • Trigger: New stock arrives or products are sold, altering inventory levels.
  • Action: InventoryService updates stock levels and emits StockLevelChanged events.
  • Event Store Involvement: These events are captured in the event store for historical tracking.
• Query Side (ProductService):
  • ProductService (acting as a query-side for inventory data) listens to these events to update real-time stock availability displayed to customers.

Scenario 10: Handling Payment Failures

• Command Side (PaymentService - Hypothetical):
  • Trigger: A payment transaction fails due to insufficient funds.
  • Action: PaymentService processes the failure and emits a PaymentFailed event.
  • Event Store Involvement: The event store records the PaymentFailed event.
• Query Side (OrderService):
  • OrderService reacts to PaymentFailed events to update the order status and initiate compensating transactions, like order cancellation or notifying the customer.

Continuing with more detailed scenarios, let's explore further how the CQRS pattern integrates with an event-driven architecture, emphasizing the role of the event store and interactions between the command and query sides.

Scenario 11: Handling Out-of-Stock Situations

• Command Side (OrderService):
  • Trigger: A customer places an order, but one of the products is out of stock.
  • Action: OrderService recognizes the out-of-stock situation and issues an OrderFailedDueToOutOfStock event.
  • Event Store Involvement: The event is logged in the event store, recording this business-critical occurrence.
• Query Side (CustomerService):
  • Response: CustomerService listens to the OrderFailedDueToOutOfStock event and updates the customer's order history to reflect the failed order.

Scenario 12: Promotional Discounts

• Command Side (ProductService):
  • Trigger: A new promotion is launched, applying discounts to certain products.
  • Action: ProductService processes the discount updates and emits ProductDiscountApplied events.
  • Event Store Involvement: Each discount event is stored, keeping a record of all promotional changes.
• Query Side (ReportingService):
  • Response: ReportingService uses the ProductDiscountApplied events to adjust its pricing and sales analytics.

Scenario 13: Customer Data Correction

• Command Side (CustomerService):
  • Trigger: A customer corrects their personal information, such as their address.
  • Action: CustomerService updates the customer's details and publishes a CustomerDetailsUpdated event.
  • Event Store Involvement: The update event is captured in the event store for consistency and audit trails.
• Query Side (OrderService):
  • Response: OrderService listens to CustomerDetailsUpdated events to maintain accurate shipping information for orders.

Scenario 14: Product Review and Ratings Update

• Command Side (ReviewService - Hypothetical):
  • Trigger: Customers submit reviews and ratings for products.
  • Action: ReviewService processes these reviews and publishes ProductReviewUpdated events.
  • Event Store Involvement: The events are stored, tracking changes in product reputation.
• Query Side (ProductService):
  • Response: ProductService (query side for reviews) updates product display information to include latest reviews and ratings.

Scenario 15: Order Delivery Status Tracking

• Command Side (ShippingService - Hypothetical):
  • Trigger: An order is shipped, and its delivery status is updated at various stages.
  • Action: ShippingService updates the delivery status and broadcasts OrderDeliveryStatusUpdated events.
  • Event Store Involvement: The event store logs these status updates, providing a traceable history of the order's shipment.
• Query Side (CustomerService):
  • Response: CustomerService consumes OrderDeliveryStatusUpdated events to provide real-time delivery tracking information to customers.

How the Event Store is Involved - Role of Event Store in CQRS

In each of these scenarios, the event store is pivotal in:

• Capturing System Changes: It acts as a ledger, recording every significant state change in the system through events.
• Ensuring Data Consistency: By storing all events, it helps in maintaining a consistent view across different services, crucial in a distributed environment.
• Enabling Event Replay: In cases where services need to rebuild their state or new query models are introduced, events from the store can be replayed.
• State Preservation: It preserves the state changes in the system as a series of events. This historical data is vital for auditing, debugging, and system analysis.
• Event Sourcing: The event store can be used to replay events to rebuild the state of a service, which is particularly useful in scenarios where a service needs to be reconstructed or in disaster recovery.
• System Integration: It acts as a central hub for all events, enabling integration between different parts of the system and ensuring that all services are updated consistently and in real-time.

CQRS Pattern and Event-Driven Architecture Advantages

1. Scalability and Performance: By separating read and write operations, each service can be scaled independently based on demand, enhancing overall system performance.
2. Flexibility and Maintainability: Each microservice focuses on either command or query functionality, simplifying development and maintenance.
3. Resilience and Reliability: The use of sagas and circuit breakers ensures the system remains functional and consistent, even in the face of partial failures or service unavailability.

Implementation Tips

• Event Design: Design events to contain all necessary data for consumers to avoid additional service calls.
• Idempotency: Ensure that event consumers are idempotent, meaning they can handle duplicate events without adverse effects.
• Monitoring and Observability: Implement comprehensive logging and monitoring to track the flow of events and the state of sagas, which is crucial for debugging and performance tuning.

Conclusion

In these detailed scenarios, each microservice in the Online Retail System plays a specific role, either producing or consuming events, and has defined actions based on those events. The sagas and compensating transactions ensure that the system maintains consistency even in failure scenarios, effectively rolling back or adjusting the system state as needed. The implementation of circuit breakers adds another layer of resilience, handling failures in external services or overloaded services by degrading functionality gracefully or retrying operations as appropriate.

This comprehensive approach demonstrates the practical application of CQRS, event-driven architecture, sagas, and circuit breakers in a microservices environment, showcasing their advantages in terms of system resilience, consistency, and user experience.

[arulsudarvizhi1]

Hi Akash ( @akash-coded ),

Please find attached the compond exercise for CQRS pattern.

1. product-service : http://localhost:8081/product ---> Tested to create a Product (Event created for the product creation), product query side updated, Consumer to update product quantity, if issue in inventory update reverseOrder (Saga pattern implemented and tested)
2. order-service --> http://localhost:8082/order ---> tested to post order through post man --> Updates inventory through event , Creates event for order creation , updates customer order transaction query side through event driven approach, consumer to reverse order
3. event-service : http://localhost:8083/eventdetails --> Listens to order, product creation and create the event store for order and product --> Tested
4. customer-queryservice : http://localhost:8084/customerqueryorder --> Consumer logic to create customer order history. API to see all customerorders tested
5. report-queryservice : Implemented listener queue for product report, RestAPI to call event store details. IF fails circuit breaker logic invoked to give default empty event store infomation ---> Code complete. Testing had issues no start up error but APIs for testing not working properly. To debug

cqrs_pattern_compoundex.zip

Name: Arul
Batch: 7-Nov to 6-Dec 7.30 am batch

[samik2023]

Hi Akash,

Here is the code ,

https://github.com/samik2023/customer-query-service
https://github.com/samik2023/order-serice
https://github.com/samik2023/event-service
https://github.com/samik2023/reporting-service
https://github.com/samik2023/product-service

Saga transaction reversals are tested and working, Few functionalities related to queryservice are pending,will try to update asap.

Regards
Samik TCS Nov 7th Morning 7.30 batch

[sowmyagardas]

Hi Akash,
Attaching the code base for Online Retail System.

Thanks,
Sowmya.
OnlineRetailSystem.zip

[misriya-git]

Hi Akash,

Please find the updated code base below.
Misriya-179-Updated.zip

Thanks & Regards,
Misriya

[raghavan-tcs]

Hi @akash-coded

Please find attached CQRS exercise using http request for book-service. Postman collection is also included.

cqrs_exercise.zip

Batch : Apr-17-2024

Thanks
Raghavan S

[Aditi-12092024]

Hi Akash,
Please find CQRS implementation -Order query service, Order command service

CQRS.zip

Thanks
Aditi Sharma