CQRS: Command Query Responsibility Segregation in Modern Architecture

In contemporary software architecture, we often encounter systems where the complexity of data retrieval differs significantly from the complexity of data modification. CQRS (Command Query Responsibility Segregation) is a pattern that addresses this asymmetry by using different models for updating and reading information.

As defined by Greg Young and popularized by Martin Fowler, CQRS is fundamentally about separating the "Command" (Write) side from the "Query" (Read) side of an application.

The core premise of CQRS is that any method should be either a Command, which performs an action and changes the state of a system but returns no data, or a Query, which returns data to the caller but does not change the state.

Failed to render diagram. Check syntax.
graph LR
    User([User])
    subgraph "Application"
        CommandBus[Command Bus]
        QueryBus[Query Bus]
        
        subgraph "Write Side"
            CH[Command Handlers]
            WM[(Write Database)]
        end
        
        subgraph "Read Side"
            QH[Query Handlers]
            RM[(Read Database)]
        end
    end
    
    User -->|Sends Command| CommandBus
    CommandBus --> CH
    CH --> WM
    
    User -->|Executes Query| QueryBus
    QueryBus --> QH
    QH --> RM
    
    WM -.->|Sync/Event| RM

Golang's structural typing and interface-first approach make it an excellent choice for implementing CQRS. By segregating these responsibilities, we can optimize the read and write models independently.

The write model focuses on domain integrity and transactional consistency. In Go, this is typically represented by a set of Command structs and their respective handlers.

EXPANDCOPY
go
// Command definition
type RegisterUser struct {
    UserID   string
    Email    string
    Password string
}

// Handler implementation
type UserCommandHandler struct {
    repository UserRepository
}

func (h *UserCommandHandler) HandleRegister(ctx context.Context, cmd RegisterUser) error {
    user, err := domain.NewUser(cmd.UserID, cmd.Email, cmd.Password)
    if err != nil {
        return err
    }
    return h.repository.Save(ctx, user)
}

The read model is optimized for the UI or external API consumers. It often uses DTOs (Data Transfer Objects) and may bypass complex domain logic entirely.

EXPANDCOPY
go
type UserReadModel struct {
    ID    string `json:"id"`
    Email string `json:"email"`
}

type UserQueryHandler struct {
    db *sql.DB
}

func (h *UserQueryHandler) GetUserByID(ctx context.Context, id string) (UserReadModel, error) {
    // Optimized SQL query directly to a read-optimized view
    var model UserReadModel
    err := h.db.QueryRowContext(ctx, "SELECT id, email FROM user_views WHERE id = ?", id).Scan(&model.ID, &model.Email)
    return model, err
}

CQRS allows you to scale and optimize your read and write operations independently. Since most applications are read-heavy, you can deploy multiple instances of your query services and read-replicas without affecting the write consistency. This is particularly useful when the read model requires complex joins or aggregations that would slow down a transactional write model.

Martin Fowler's primary advice regarding CQRS is that most systems should stay CRUD. CQRS introduces a significant "mental leap" and architectural overhead. It should not be the default architecture for an entire system, but rather applied to specific Bounded Contexts where the complexity of the domain justifies the cost.

Key risks include:

• Eventual Consistency: If using separate databases, the read model will lag behind the write model.

• Code Duplication: Managing two models can lead to boilerplate if not handled carefully.

• Overkill: Applying CQRS to a simple data-entry application is a classic architectural anti-pattern.

While CQRS and Event Sourcing are frequently mentioned together, they are distinct patterns. CQRS allows you to use separate models for reads and writes. Event Sourcing ensures that every change to the state is captured as an event.

You can use CQRS without Event Sourcing (using a standard relational database for the write side) and vice versa, though they are highly complementary in high-scale distributed systems.

CQRS is a powerful tool when applied to the right problems. By acknowledging that reading and writing are fundamentally different behaviors, architects can build more resilient and performant systems. However, as with any advanced pattern, the first rule of CQRS is: don't use it unless you truly need it.