Understanding CQRS with Real-Life Examples

-

 

1. CQRS in an Online Store (Real-Life Example)




In this diagram, we see an online store architecture applying CQRS:

  • API Gateway: The entry point for all client requests. It routes incoming calls to the right backend service.

  • Frontend Service: Connects to various backend services depending on the operation.

  • Products Service (Write Side): Responsible for updating product information (e.g., adding new products, changing prices, updating stock).

  • Products Search Service (Read Side): Maintains a denormalized, read-optimized view of product data so customers can quickly search and filter products.

  • Reviews Service: Handles user reviews separately, but it also feeds into the search service so that reviews can be displayed alongside products.

Notice that the Products Service and the Products Search Service do not share the same database. Instead, updates from the Products Service trigger events (via message queues or change notifications), and the Search Service builds a read-optimized view for fast queries.

This ensures that the online store can handle heavy read loads (product searches) efficiently, without slowing down the write operations (stock updates, price changes).

2. Separation of Update and Read Operations




The second diagram illustrates the core principle of CQRS — separating reads and writes:

  • Service A (Write Side): Handles update operations. It writes to a write-optimized database, which is usually normalized to enforce business rules and consistency.

  • Service B (Read Side): Handles read operations. It queries a read-optimized database, often denormalized for speed and tailored to the queries the application needs.

  • Message Broker: Acts as a bridge between the two sides. When Service A makes updates, it sends events/messages to the broker. Service B consumes these messages to keep its read database in sync with the latest state.

This pattern allows the system to scale efficiently:

  • Reads (which usually account for 80–90% of traffic) can be scaled independently.

  • Writes can remain strict and consistent without slowing down read queries.

Why CQRS Matters

By splitting reads and writes, CQRS provides:

  • Performance: Queries become faster thanks to read-optimized models.

  • Scalability: Read and write workloads can scale separately.

  • Flexibility: Different databases can be used for different purposes (e.g., SQL for writes, NoSQL for reads).

  • Event-driven architecture: Easily integrates with event sourcing and message brokers.

Of course, CQRS also adds complexity. It’s most valuable in large-scale, high-performance systems, such as e-commerce, financial services, and IoT platforms.

✅ In short:
The first image shows a real-world e-commerce implementation of CQRS, where product updates and searches are handled by separate services.
The second image illustrates the theoretical principle — how updates and reads use separate services, databases, and a message broker to stay in sync.

Comments

Post a Comment

Popular posts from this blog

REST vs RPC vs GraphQL: Choosing the Right API Style

-
 APIs are the glue that connects modern applications. Whether you’re building a public-facing service or a complex microservices ecosystem, the design style of your API plays a huge role in performance, usability, and maintainability. Three common approaches dominate today’s landscape: REST , RPC , and GraphQL . Each comes from a different philosophy, and each has strengths and trade-offs. Let’s compare them. 1. REST (Representational State Transfer) REST treats everything as a resource and interacts with those resources using standard HTTP methods. It’s resource-oriented and built on the web’s existing semantics. Example : GET / users / 123 → fetch user 123 PUT / users / 123 → update user 123 GET / users / 123 / orders → fetch orders for user 123 ✅ Pros Standardized and predictable Widely supported by tools and libraries Leverages HTTP features (caching, status codes, headers) Great for resource-centric systems ❌ Cons ...
Read more

Fibonacci Agile Estimation

-
Image
  Most agile teams opt to combine the Fibonacci sequence with an estimation method called   planning poker . In Planning Poker, each team member has a modified deck of cards that corresponds with the Fibonacci sequence. When a task is up for estimation, each member individually picks a card that best matches their estimate for that item. Everyone then reveals their cards simultaneously and discusses their estimates until they reach a consensus. Why is the Fibonacci sequence used in agile estimation? The point of Fibonacci is to force your hand when estimating larger, complex tasks instead of wasting time nitpicking over minor differences . This is best explained through an example that compares simple time-based estimation with Fibonacci estimation. Let’s say you estimated your stories on a steady scale of 1-50.  When you discuss your backlog item with the team, one picks 31, the other 36, and a third 38. When the gap between each estimate is a single integer it’s hard to...
Read more

How to Add LICENSE.txt to Your .NET Project Using Azure Pipelines

-
Image
   Including a license file in your NuGet package is a best practice that improves transparency and compliance for your open-source or internal packages. If you store your   LICENSE.txt   securely in Azure DevOps, you can automate its inclusion into your .NET project using Azure Pipelines. In this guide, I’ll walk you through how to: Download the LICENSE.txt from Azure DevOps secure files Copy the file into your project directory Modify the .csproj file dynamically to include the license file during build and packaging 🔐 Step 1: Download  LICENSE.txt  from Secure Files First, upload your  LICENSE.txt  to the  Secure Files  library in Azure DevOps. Then, in your YAML pipeline, use the  DownloadSecureFile  task to fetch it at runtime. - task: DownloadSecureFile@1 displayName: 'Download LICENSE.txt' inputs: secureFile: 'LICENSE.txt' This will download the file to a temporary location on the build agent ( $(Agent.Te...
Read more