CQRS & Event Sourcing Architecture

1) Problem Clarification / Làm rõ bài toán

EN

Traditional CRUD systems maintain state directly.
However, in high-scale distributed environments, state mutation needs:

auditability
replayability
async data projection
versioning

=> CQRS + Event Sourcing fits this.

VI

CRUD truyền thống update state trực tiếp.
Trong hệ thống phân tán scale lớn, cần:

audit
replay
async projection
version

=> CQRS + Event Sourcing phù hợp.

2) CQRS Principle / Nguyên lý CQRS

EN

Separate:

Command side (write model)
Query side (read model)

Each optimized differently.

VI

Tách:

Command để ghi
Query để đọc

Tối ưu độc lập.

3) Why CQRS? / Vì sao dùng CQRS?

EN

✔ optimize reads
✔ allow async projection
✔ isolate write transactional consistency
✔ resilient scaling

VI

✔ tối ưu đọc
✔ async projection
✔ hơn về consistency cho ghi
✔ scale tốt

4) Event Sourcing Principle / Nguyên lý Event Sourcing

EN

Instead of storing final state, store events:

account credited +$100
account debited -$20

State reconstructed by applying events.

VI

Không lưu state cuối, mà lưu events:

cộng 100
trừ 20

State = apply các event.

5) Architectural Overview / Kiến trúc tổng quan

Command API → Event Store → Async Projections → Read Store
                             ↘ Replay

VI

Flow:

Command API → Event Store → Projections → Read DB

6) Event Store Model / Event Store

EN

Store append-only log:

EVENT (
   aggregate_id,
   event_type,
   payload,
   ts,
   version
)

VI

Event Store append-only:

EVENT (
   aggregate_id,
   type,
   payload,
   ts,
   version
)

7) Projection Layer / Tầng projection

EN

Projections transform events into:

query views
history logs
analytics
cache

Executed asynchronously.

VI

Projection biến event thành:

view query
log lịch sử
analytics
cache

Xử lý async.

8) Handling Failures / Xử lý lỗi

EN

projection errors → retry or DLQ
event replay needed for reconstruction
version conflicts require optimistic concurrency control

VI

lỗi projection → retry / DLQ
cần replay để rebuild
version conflict → OCC xử lý

9) Query Model / Mô hình đọc

EN

Query side maintains materialized views:

balance per account
transaction list
leaderboard ranking

VI

Query giữ view vật lý:

balance  
transaction log  
leaderboard

10) Benefits / Lợi ích

EN

✔ full history
✔ audit trail
✔ rebuildable read models
✔ eventual consistency isolation

VI

✔ full history
✔ audit
✔ rebuild view
✔ consistency tách biệt

11) Trade-offs / Nhược điểm

EN

increased complexity
event versioning required
debugging async processes
replay latency

VI

phức tạp hơn CRUD
cần version event
debug async khó
replay có latency

12) Example Use Cases / Use case thực tế

EN

Banking/ledger
Order management
Gaming scoring
IoT telemetry aggregation

VI

banking
order mgmt
game scoring
IoT aggregation

13) Event Rebuild & Replay / Rebuild lại state

EN

When read model lost → reapply events to regenerate it.

VI

Mất read model? → replay events rebuild lại.

14) Observability & Governance / Giám sát

EN

event audit dashboards
projection lag
compensation action logs

VI

dashboard audit
projection lag
log compensation

15) When Not To Use CQRS / Khi không nên dùng CQRS

EN

simple CRUD app
single DB small system
requirements unclear

VI

Không nên dùng cho:

CRUD đơn giản
app nhỏ
yêu cầu chưa ổn định