Thay vì lưu 'số dư = 200' rồi ghi đè mỗi lần đổi, event sourcing lưu từng sự kiện (nạp 100, rút 30, nạp 50...) và tính trạng thái bằng cách replay chúng. Bài này chạy thật trên Kafka: replay toàn bộ event log dựng lại balance 200, time-travel về quá khứ cho balance 100 tại thời điểm cũ, thêm event rồi replay vẫn đúng 700, và toàn bộ 7 sự kiện còn nguyên làm audit. Đổi lại là chi phí replay.
Đặt một đơn hàng cần trừ kho, trừ tiền, tạo đơn — ở ba service khác nhau, không có transaction chung để 'commit cả ba hoặc không gì'. Saga giải quyết bằng chuỗi bước cục bộ, mỗi bước có bước bù trừ. Bài này chạy thật trên PostgreSQL: saga thành công trừ kho/tiền và tạo đơn khớp; saga lỗi ở bước tiền tự hoàn kho đã trừ và không tạo đơn, đưa hệ về đúng trạng thái ban đầu.
Producer và consumer deploy không đồng bộ — producer gửi message phiên bản mới trong khi consumer cũ còn chạy, và ngược lại. Bài này chạy thật bằng Go: thêm field optional thì consumer mới đọc message cũ vẫn ổn (currency mặc định VND), consumer cũ đọc message mới thì bỏ qua field lạ; nhưng đổi kiểu field cho lỗi parse to, còn đổi tên field gây mất dữ liệu âm thầm (amount=0 mà không báo lỗi). Quy tắc: chỉ thêm field optional.
Mười một phần qua ta dựng từng mảnh của hệ message queue bằng demo đo thật. Bài cuối ghép chúng lại: một pipeline hoàn chỉnh produce 500 order qua Kafka, giao trùng 1000 lượt theo at-least-once, rồi consumer idempotent xử lý đúng 500 — tất cả patterns làm việc cùng nhau. Kèm bảng tổng hợp mọi con số đo thật xuyên 12 bài và một khung quyết định chọn dùng pattern nào khi nào.
REST + JSON có mặt khắp nơi và dễ đọc — vậy vì sao nhiều hệ chuyển sang gRPC cho giao tiếp nội bộ? Bài này đo thật: cùng một Order, protobuf chỉ 26 byte so với JSON 70 byte (gọn hơn 63%), và một unary gRPC call đạt gần 14.000 call/s với 0,072 ms/call. Giải thích vì sao protobuf nhỏ thế, gRPC nhanh thế, và cái giá phải trả: cần .proto, codegen, và byte nhị phân không đọc được bằng mắt.
Bài trước đo được protobuf gọn hơn JSON 63% nhưng chưa nói vì sao. Bài này mổ xẻ từng byte: serialize {id:1001, name:abc, big:7} ra 11 byte rồi giải mã thủ công — 08 là tag field 1, e907 là varint 1001, a001 là tag field 20 tốn 2 byte. Đo thật varint co giãn theo giá trị (id 5 tốn 2 byte, id 10 tỷ tốn 6 byte), và vì sao wire chỉ chứa số field nên đổi tên không phá nhưng đổi field number thì phá.