CQRS Pattern in Java – Separate Read and Write Models for Scalable Applications

Introduction

Most traditional CRUD-based applications handle read and write operations through the same model. While simple, this approach often struggles when dealing with complex business rules, scaling bottlenecks, and performance optimization.

That’s where CQRS (Command Query Responsibility Segregation) steps in.

CQRS is a design pattern that separates the read and write models of an application, enabling better scalability, maintainability, and performance.

🧠 What Is the CQRS Pattern?

Command Query Responsibility Segregation (CQRS) is a pattern that divides a system’s operations into two distinct parts:

Commands: Operations that change state (Create, Update, Delete)
Queries: Operations that retrieve data (Read-only)

By decoupling these responsibilities, each side can be optimized independently.

UML Diagram

[Client]
   |                          |
   |---> [Command Handler]    |---> [Query Handler]
           |                       |
           v                       v
      [Write Model]         [Read Model]
           |                       |
        [DB A]                  [DB B / View]

👥 Core Participants

Command: Intent to change state.
Command Handler: Executes business logic and updates write DB.
Query: Request for data.
Query Handler: Fetches data from read-optimized DB or view.
Event Bus (optional): Propagates changes from write model to read model.

🌍 Real-World Use Cases

Banking apps: Update balance (command), view statement (query).
E-commerce: Place order (command), view product catalog (query).
Task managers: Add task vs. list upcoming tasks.
Auditing systems with immutable event logs.

🧰 Implementation in Java (Spring Boot)

1. Define Command

public record CreateUserCommand(String name, String email) {}

2. Command Handler

@Service
public class UserCommandHandler {

    @Autowired
    private UserRepository userRepository;

    public void handle(CreateUserCommand command) {
        User user = new User(command.name(), command.email());
        userRepository.save(user);
    }
}

3. Query Model

public record UserDTO(Long id, String name, String email) {}

4. Query Handler

@Service
public class UserQueryHandler {

    @Autowired
    private UserReadRepository readRepository;

    public List<UserDTO> getAllUsers() {
        return readRepository.findAll()
            .stream()
            .map(u -> new UserDTO(u.getId(), u.getName(), u.getEmail()))
            .toList();
    }
}

✅ Pros and Cons

Pros	Cons
Optimized for reads and writes	Added architectural complexity
Better scalability in high-traffic systems	Eventual consistency between models
Clear separation of concerns	Synchronization challenges
Supports event sourcing and auditability	Requires more infrastructure (event bus)

❌ Anti-Patterns

Using same model for read/write but calling it CQRS
Ignoring read-model synchronization
Treating CQRS as a silver bullet for small projects
Not designing commands as intention-driven actions

Pattern	Purpose
CQRS	Separate read and write models
CRUD	Unified model for all operations
Event Sourcing	Store changes as a series of events
Mediator	Decouple request from handling

💻 Java Code: Using Axon Framework for CQRS

@Aggregate
public class UserAggregate {

    @CommandHandler
    public UserAggregate(CreateUserCommand cmd) {
        AggregateLifecycle.apply(new UserCreatedEvent(cmd.name(), cmd.email()));
    }

    @EventSourcingHandler
    public void on(UserCreatedEvent event) {
        // Update state
    }
}

🔧 Refactoring Legacy Code

Before (CRUD-style)

public User createUser(String name, String email) {
    return repository.save(new User(name, email));
}

public List<User> getAllUsers() {
    return repository.findAll();
}

After (CQRS-style)

Split into UserCommandHandler and UserQueryHandler
Create a read model projection table or cache

🌟 Best Practices

Design commands as intent (not just DTOs)
Keep read models denormalized for performance
Use asynchronous message/event queues for syncing models
Leverage DDD aggregates on the command side
Use database views or NoSQL stores for queries

🧠 Real-World Analogy

Think of a restaurant: Waiters take orders (commands), kitchen processes them, while customers check the digital menu (query). You can view the menu without affecting the kitchen process—separation of command and query.

☕ Java Feature Relevance

Records: Perfect for commands, queries, and DTOs.
Sealed Classes: Use for defining bounded types of commands.
Streams: Ideal for transforming query results.

🔚 Conclusion & Key Takeaways

The CQRS pattern offers a powerful way to build scalable, maintainable, and high-performance Java applications, especially in distributed systems and event-driven architectures.

✅ Summary:

Split reads and writes to reduce complexity.
Use domain models for commands, DTOs for queries.
Optimize each side independently.
Monitor and sync changes properly.

❓ FAQ – CQRS Pattern in Java

1. What is the CQRS pattern?

A pattern that separates read and write responsibilities into different models and paths.

2. Do I need two databases for CQRS?

Not always. You can use views or tables in the same DB initially.

3. Is CQRS overkill for small apps?

Yes. Use only when you have clear performance, complexity, or scaling needs.

4. What’s the difference between CQRS and CRUD?

CRUD uses a single model; CQRS splits them.

5. Is CQRS tied to event sourcing?

No, but they are often used together.

6. Can I implement CQRS without a framework?

Yes. Use service-layer handlers manually.

7. What is a read model?

A denormalized view optimized for querying.

8. Does CQRS improve performance?

Yes, especially for large-scale read-heavy systems.

9. Which Java tools support CQRS?

Axon Framework, Spring Boot, Eventuate.

10. How do I sync read/write models?

Using events, polling, or scheduled tasks depending on your architecture.