Doanh nghiệpEnterprise

CQRSaka Command Query Responsibility Segregation

Tách mô hình GHI (command) và mô hình ĐỌC (query) để tối ưu từng bên riêng.Split the WRITE model (commands) from the READ model (queries) so each can be optimised on its own.

Độ khóDifficulty: KhóHard
Mức phổ biếnUsage: Mức phổ biếnUsage 3/5
Thời gian đọcReading time: ~9 phút đọc~9 min read

Thảo luậnDiscussion

Ví dụ đời thườngReal-life analogy

Ở quán phở đông khách: bếp (ghi) làm việc theo quy trình chặt — nhận order, kiểm tra nguyên liệu, nấu. Còn bảng menu treo tường (đọc) chỉ cần to, rõ, đọc nhanh, và được cập nhật khi bếp hết món. Không ai bắt khách vào bếp lục sổ nhập hàng chỉ để xem hôm nay còn phở bò không.In a busy pho shop, the kitchen (writes) follows a strict process — take the order, check ingredients, cook. The menu board on the wall (reads) just needs to be big, clear and fast to read, updated when the kitchen runs out of something. Nobody makes customers dig through the kitchen's stock ledger to see if beef pho is still available.

Vấn đề và giải phápProblem and solution

Không có patternWithout the pattern

Bảng orders được chuẩn hoá đẹp cho việc ghi (orders, order_lines, payments, shipments). Nhưng màn 'Đơn hàng của tôi' cần JOIN 5 bảng, GROUP BY, đếm số món, lấy trạng thái giao hàng mới nhất... Ngày sale, hàng triệu lượt đọc đè lên cùng database đang phải ghi đơn — query chậm, lock tranh chấp, và entity JPA phình to vì phải phục vụ cả hai mục đích.The orders schema is nicely normalized for writes (orders, order_lines, payments, shipments). But the 'My orders' screen needs a 5-table JOIN, GROUP BY, item counts, latest delivery status... On sale day, millions of reads pile onto the same database that is busy writing orders — slow queries, lock contention, and JPA entities bloated from serving both purposes.

Với CQRSWith CQRS

Chia làm hai phía. Phía Command nhận ý định (PlaceOrder, CancelOrder), kiểm tra quy tắc nghiệp vụ trên mô hình ghi chuẩn hoá, rồi phát event. Một Projector lắng nghe event và cập nhật read model đã phi chuẩn hoá sẵn (bảng order_summary, Elasticsearch, Redis). Phía Query chỉ SELECT phẳng từ read model, có thể đặt trên read replica và scale độc lập. Đổi lại, phía đọc trễ vài mili-giây đến vài giây (eventual consistency).Split into two sides. The Command side receives intents (PlaceOrder, CancelOrder), enforces business rules on the normalized write model, then emits events. A Projector listens to those events and updates a pre-denormalized read model (an order_summary table, Elasticsearch, Redis). The Query side only does flat SELECTs on the read model, can sit on a read replica and scales independently. The price: reads lag by milliseconds to seconds (eventual consistency).

Thành phần tham giaParticipants

Command: Ý định thay đổi trạng thái (PlaceOrder) — không trả về dữ liệu hiển thị.An intent to change state (PlaceOrder) — returns no view data.
Command handler + write model: Kiểm tra invariant, ghi vào mô hình chuẩn hoá, phát event.Enforces invariants, writes the normalized model, emits events.
Projector: Nghe event, cập nhật read model phi chuẩn hoá.Listens to events and updates the denormalized read model.
Query handler + read model: Trả DTO phẳng, nhanh, từ read store/replica.Returns flat, fast DTOs from the read store/replica.

Sơ đồ và luồng thực thiDiagram and execution flow

Dùng Tự chạy hoặc phím mũi tên để đi qua từng bước gọi giữa các object. Console hiển thị output tương ứng của chương trình.Use Autoplay or the arrow keys to step through each call between objects. The console shows the matching program output.

1Khách bấm 'Đặt hàng': controller gửi command PlaceOrder sang phía ghi.The customer clicks 'Place order': the controller sends a PlaceOrder command to the write side.

← →

console

1> POST /orders (PlaceOrder, 3 lines)

implementsimplementsextendsextendsgọi / dùngcalls / usestạo racreatesgửi qua channelsends via channel1thứ tự chạy (bấm để nhảy bước)execution order (click to jump)

Code: Java Spring Boot ⇄ GoCode: Java Spring Boot ⇄ Go

Cùng một bài toán, hai ngôn ngữ. Rê chuột hoặc focus vào chú thích (số màu cam) để làm nổi bật dòng code tương ứng.Same problem, two languages. Hover or focus an annotation (orange number) to highlight its line.

JavaSpring Boot 3 · Java 21Spring Boot 3 · Java 21

package com.shop.order.command;

import java.util.List;
import java.util.UUID;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class OrderCommandService {
    // Commands = intents. Named in the imperative, carry only input data.
    public record PlaceOrder(UUID customerId, List<OrderLine> lines) {}1
    public record CancelOrder(UUID orderId, String reason) {}

    private final OrderRepository orders; // JPA, normalized write model
    private final ApplicationEventPublisher events;

    public OrderCommandService(OrderRepository orders, ApplicationEventPublisher events) {
        this.orders = orders;
        this.events = events;
    }

    @Transactional
    public UUID handle(PlaceOrder cmd) {
        Order order = Order.place(cmd.customerId(), cmd.lines()); // invariants live here2
        orders.save(order);
        events.publishEvent(new OrderPlaced(3
            order.id(), cmd.customerId(), order.total(), cmd.lines().size()));
        return order.id(); // just the id, never a view4
    }

    @Transactional
    public void handle(CancelOrder cmd) {
        Order order = orders.findById(cmd.orderId())
            .orElseThrow(() -> new OrderNotFoundException(cmd.orderId()));
        order.cancel(cmd.reason()); // throws if already shipped
        events.publishEvent(new OrderCancelled(order.id(), cmd.reason()));
    }
}

GoGo 1.23 · thư viện chuẩnGo 1.23 · standard library

package order

import (
	"context"
	"database/sql"
	"errors"
	"log/slog"

	"github.com/google/uuid"
)

type PlaceOrder struct {1
	CustomerID string
	Lines      []Line
}

type Line struct {
	SKU   string
	Qty   int
	Price int64 // VND
}

type Publisher interface{ Publish(ctx context.Context, event any) error }

type CommandHandler struct {
	DB  *sql.DB // primary (write) database
	Bus Publisher
}

func (h *CommandHandler) PlaceOrder(ctx context.Context, cmd PlaceOrder) (string, error) {
	if len(cmd.Lines) == 0 {2
		return "", errors.New("order needs at least one line")
	}
	id := uuid.NewString()
	var total int64
	for _, l := range cmd.Lines {
		total += l.Price * int64(l.Qty)
	}
	tx, err := h.DB.BeginTx(ctx, nil)
	if err != nil {
		return "", err
	}
	defer tx.Rollback() // no-op after Commit
	if _, err := tx.ExecContext(ctx, "INSERT INTO orders (id, customer_id, total, status) VALUES ($1, $2, $3, 'PLACED')", id, cmd.CustomerID, total); err != nil {
		return "", err
	}
	for _, l := range cmd.Lines {
		if _, err := tx.ExecContext(ctx, "INSERT INTO order_lines (order_id, sku, qty, price) VALUES ($1, $2, $3, $4)", id, l.SKU, l.Qty, l.Price); err != nil {
			return "", err
		}
	}
	if err := tx.Commit(); err != nil {
		return "", err
	}
	ev := OrderPlaced{OrderID: id, CustomerID: cmd.CustomerID, Total: total, ItemCount: len(cmd.Lines)}
	if err := h.Bus.Publish(ctx, ev); err != nil {3
		slog.Error("publish failed, read model will lag", "order", id, "err", err) // see Transactional Outbox
	}
	return id, nil
}

Khác biệt chính giữa Java và GoKey differences between Java and Go

01Spring có sẵn ApplicationEventPublisher + @TransactionalEventListener(AFTER_COMMIT) để nối command và projection. Go tự nối bằng channel/Kafka consumer và goroutine.Spring ships ApplicationEventPublisher + @TransactionalEventListener(AFTER_COMMIT) to connect commands to projections. Go wires it by hand with channels/Kafka consumers and goroutines.
02Java thường dùng JPA cho phía ghi và JdbcTemplate/jOOQ cho phía đọc. Go thường dùng database/sql (hoặc sqlc) cho cả hai — CQRS ở đây là tách struct và *sql.DB, không phải tách framework.Java often uses JPA for writes and JdbcTemplate/jOOQ for reads. Go typically uses database/sql (or sqlc) for both — CQRS there means separate structs and *sql.DB handles, not separate frameworks.
03Định tuyến event: Spring chọn listener theo kiểu tham số của method on(...). Go dùng type switch switch e := ev.(type) tường minh.Event routing: Spring picks the listener by the parameter type of on(...). Go uses an explicit type switch switch e := ev.(type).
04Replica: Spring cần 2 DataSource + @Qualifier (hoặc AbstractRoutingDataSource). Go chỉ cần mở 2 *sql.DB và truyền đúng cái vào đúng handler.Replicas: Spring needs 2 DataSources + @Qualifier (or AbstractRoutingDataSource). Go just opens 2 *sql.DB values and passes the right one to each handler.

Ứng dụng thực tếReal-world usage

Axon Framework (Java)Axon Framework (Java)
Framework CQRS + Event Sourcing phổ biến nhất cho Spring Boot: @CommandHandler, @EventHandler, @QueryHandler, kèm Axon Server làm event store.The most popular CQRS + Event Sourcing framework for Spring Boot: @CommandHandler, @EventHandler, @QueryHandler, with Axon Server as the event store.
Read replica + ElasticsearchRead replicas + Elasticsearch
Dạng CQRS nhẹ nhất: ghi vào PostgreSQL primary, đọc từ replica; tìm kiếm sản phẩm thì đồng bộ sang Elasticsearch qua Debezium/Kafka.The lightest CQRS: write to the PostgreSQL primary, read from replicas; product search syncs to Elasticsearch via Debezium/Kafka.
Go: Watermill, EventStoreDB clientGo: Watermill, EventStoreDB client
ThreeDotsLabs/watermill có package cqrs với CommandBus/EventBus chạy trên Kafka, NATS, SQL.ThreeDotsLabs/watermill has a cqrs package with CommandBus/EventBus over Kafka, NATS or SQL.
Dashboard ví điện tử, sao kê ngân hàngE-wallet dashboards, bank statements
Giao dịch ghi vào sổ cái chuẩn hoá; màn 'Lịch sử giao dịch' và báo cáo đọc từ bảng tổng hợp sẵn theo ngày/tháng.Transactions are written to a normalized ledger; the 'Transaction history' screen and reports read from pre-aggregated daily/monthly tables.

Khi nào dùng và khi nào khôngWhen to use it, and when not

Nên dùng khiUse it when

Lượng đọc lớn hơn lượng ghi nhiều lần và màn hình đọc cần dữ liệu tổng hợp/phi chuẩn hoá.Reads vastly outnumber writes and read screens need aggregated/denormalized data.
Nghiệp vụ ghi phức tạp (nhiều quy tắc) trong khi phía đọc cần nhiều 'góc nhìn' khác nhau (app, admin, báo cáo, search).Complex write logic (many rules) while reads need many different 'views' (app, admin, reports, search).
Cần scale đọc và ghi độc lập, hoặc đã dùng Event Sourcing (bắt buộc phải có read model).Reads and writes must scale independently, or you already use Event Sourcing (which requires read models).

Không nên dùng khiAvoid it when

Ứng dụng CRUD đơn giản: thêm projection, event, hai model chỉ tăng gấp đôi code.Simple CRUD apps: projections, events and two models just double the code.
Nghiệp vụ bắt buộc đọc ngay sau khi ghi phải thấy dữ liệu mới (read-your-writes) mà team không xử lý được độ trễ.The business requires read-your-writes immediately and the team can't handle the lag.

Ưu điểmPros

Mỗi phía có mô hình tối ưu riêng: ghi giàu quy tắc, đọc phẳng và nhanh.Each side gets an optimal model: rule-rich writes, flat fast reads.
Scale đọc độc lập (replica, cache, search engine) mà không ảnh hưởng phía ghi.Scale reads independently (replicas, caches, search engines) without affecting writes.
Dễ thêm read model mới cho màn hình mới chỉ bằng một projector.Adding a read model for a new screen is just one more projector.

Nhược điểmCons

Eventual consistency: dữ liệu đọc có thể trễ, UI và nghiệp vụ phải chấp nhận.Eventual consistency: reads can lag, the UI and the business must accept it.
Nhiều thành phần hơn (event, projector, read store) — khó debug khi read model lệch.More moving parts (events, projectors, read stores) — harder to debug a drifting read model.
Cần cơ chế rebuild projection khi đổi cấu trúc read model.You need a way to rebuild projections when the read model's shape changes.

Anti-pattern: lỗi thường gặpAnti-pattern: common mistake

Command trả về view đầy đủ, query đi sửa dữ liệuCommands return full views, queries mutate data

Command handler trả về DTO hiển thị bằng cách query lại read model ngay sau khi ghi — nhưng read model chưa kịp cập nhật nên trả dữ liệu cũ. Tệ hơn, method 'get' lại tiện tay cập nhật last_viewed_at. Hai phía dính chặt vào nhau, mất hết lợi ích của CQRS.The command handler returns a view DTO by re-querying the read model right after writing — but the read model hasn't caught up, so it returns stale data. Worse, a 'get' method conveniently updates last_viewed_at. The two sides are glued back together and CQRS loses all its benefits.

@Transactional
public OrderSummaryView handle(PlaceOrder cmd) {
    Order order = orders.save(Order.place(cmd.customerId(), cmd.lines()));
    events.publishEvent(new OrderPlaced(order.id(), cmd.customerId(), order.total(), 1));
    return queries.findById(order.id()); // ❌ projection not updated yet -> stale/empty
}

public List<OrderSummaryView> myOrders(UUID customerId) {
    customers.touchLastViewed(customerId);  // ❌ a query that writes
    return queries.byCustomer(customerId);
}

Dễ nhầm vớiEasily confused with

CQRS vs Event Sourcing

CQRS tách mô hình đọc/ghi; Event Sourcing lưu trạng thái dưới dạng chuỗi event. Hay đi chung nhưng độc lập: CQRS có thể dùng bảng thường cho phía ghi.CQRS separates read/write models; Event Sourcing stores state as a sequence of events. Often paired but independent: CQRS can use plain tables on the write side.

CQRS vs Repository

Repository trừu tượng hoá truy cập dữ liệu cho MỘT model; CQRS tách hẳn thành hai model với hai đường đi khác nhau.Repository abstracts data access for ONE model; CQRS splits into two models with two different paths.

Bài tập áp dụngExercise

Shop cần màn 'Top 10 sản phẩm bán chạy hôm nay' cho admin. Thiết kế read model và projector cho nó, dựa trên event OrderPlaced (có danh sách SKU + số lượng) và OrderCancelled.The shop needs a 'Top 10 best sellers today' admin screen. Design a read model and a projector for it, based on OrderPlaced (with SKUs + quantities) and OrderCancelled events.

Kiểm tra kiến thứcKnowledge check

Câu 1 / 6Question 1 of 6

Ý tưởng cốt lõi của CQRS là gì?What is the core idea of CQRS?

Phím 1–4 để chọn đáp án, Enter để kiểm tra.Press 1–4 to choose an answer, Enter to check.

Thẻ ghi nhớFlashcards

Ôn tập ngắt quãng (spaced repetition): thẻ được lặp lại sau 1 → 3 → 7 → 14 → 30 ngày để củng cố trí nhớ dài hạn.Spaced repetition: cards are repeated after 1 → 3 → 7 → 14 → 30 days to build long-term memory.

Dùng trong bài toánUsed in problems

3 bài toán Backend dùng pattern này3 backend problems use this pattern

Pattern liên quanRelated patterns

Event Sourcing Transactional Outbox Repository Data Transfer Object

Thảo luậnDiscussion

CQRSaka Command Query Responsibility Segregation

Tách mô hình GHI (command) và mô hình ĐỌC (query) để tối ưu từng bên riêng.Split the WRITE model (commands) from the READ model (queries) so each can be optimised on its own.

KhóHard

Mức phổ biếnUsage 3/5

~9 phút đọc~9 min read

package com.shop.order.command; import java.util.List; import java.util.UUID; import org.springframework.context.ApplicationEventPublisher; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; @Service public class OrderCommandService { // Commands = intents. Named in the imperative, carry only input data. public record PlaceOrder(UUID customerId, List<OrderLine> lines) {}1 public record CancelOrder(UUID orderId, String reason) {} private final OrderRepository orders; // JPA, normalized write model private final ApplicationEventPublisher events; public OrderCommandService(OrderRepository orders, ApplicationEventPublisher events) { this.orders = orders; this.events = events; } @Transactional public UUID handle(PlaceOrder cmd) { Order order = Order.place(cmd.customerId(), cmd.lines()); // invariants live here2 orders.save(order); events.publishEvent(new OrderPlaced(3 order.id(), cmd.customerId(), order.total(), cmd.lines().size())); return order.id(); // just the id, never a view4 } @Transactional public void handle(CancelOrder cmd) { Order order = orders.findById(cmd.orderId()) .orElseThrow(() -> new OrderNotFoundException(cmd.orderId())); order.cancel(cmd.reason()); // throws if already shipped events.publishEvent(new OrderCancelled(order.id(), cmd.reason())); } }

package order import ( "context" "database/sql" "errors" "log/slog" "github.com/google/uuid" ) type PlaceOrder struct {1 CustomerID string Lines []Line } type Line struct { SKU string Qty int Price int64 // VND } type Publisher interface{ Publish(ctx context.Context, event any) error } type CommandHandler struct { DB *sql.DB // primary (write) database Bus Publisher } func (h *CommandHandler) PlaceOrder(ctx context.Context, cmd PlaceOrder) (string, error) { if len(cmd.Lines) == 0 {2 return "", errors.New("order needs at least one line") } id := uuid.NewString() var total int64 for _, l := range cmd.Lines { total += l.Price * int64(l.Qty) } tx, err := h.DB.BeginTx(ctx, nil) if err != nil { return "", err } defer tx.Rollback() // no-op after Commit if _, err := tx.ExecContext(ctx, "INSERT INTO orders (id, customer_id, total, status) VALUES ($1, $2, $3, 'PLACED')", id, cmd.CustomerID, total); err != nil { return "", err } for _, l := range cmd.Lines { if _, err := tx.ExecContext(ctx, "INSERT INTO order_lines (order_id, sku, qty, price) VALUES ($1, $2, $3, $4)", id, l.SKU, l.Qty, l.Price); err != nil { return "", err } } if err := tx.Commit(); err != nil { return "", err } ev := OrderPlaced{OrderID: id, CustomerID: cmd.CustomerID, Total: total, ItemCount: len(cmd.Lines)} if err := h.Bus.Publish(ctx, ev); err != nil {3 slog.Error("publish failed, read model will lag", "order", id, "err", err) // see Transactional Outbox } return id, nil }

@Transactional public OrderSummaryView handle(PlaceOrder cmd) { Order order = orders.save(Order.place(cmd.customerId(), cmd.lines())); events.publishEvent(new OrderPlaced(order.id(), cmd.customerId(), order.total(), 1)); return queries.findById(order.id()); // ❌ projection not updated yet -> stale/empty } public List<OrderSummaryView> myOrders(UUID customerId) { customers.touchLastViewed(customerId); // ❌ a query that writes return queries.byCustomer(customerId); }