Service ghi đơn hàng vào database rồi publish message sang Kafka — hai bước riêng. Nếu crash giữa hai bước, database có đơn mà message biến mất. Bài này chạy thật: dual-write để lệch 40/100 đơn; outbox pattern ghi business row và outbox row trong cùng một transaction PostgreSQL, relay đọc và publish — khớp 100%, và relay chạy lại vẫn an toàn. Chìa khoá là tính nguyên tử của database.
Viết vòng lặp retry bằng tay ở từng chỗ gọi là lặp code và dễ sai. gRPC có retry policy khai bằng cấu hình. Bài này chạy thật: server fail 2 lần đầu với Unavailable rồi OK — client cấu hình retry tự thử lại và nhận thành công sau đúng 3 lần gọi server (đo bằng counter thật), với backoff tăng dần. Nhưng lỗi InvalidArgument thì không retry: server chỉ bị gọi 1 lần, vì gọi lại input sai vẫn sai.
Bài 1 nói gRPC khó debug vì byte nhị phân và cần codegen. Reflection gỡ đúng nỗi đau đó. Bài này chạy thật: server bật reflection một dòng, rồi grpcurl — curl cho gRPC — liệt kê service, xem schema message, và gọi GetOrder nhận về JSON, tất cả KHÔNG cần file .proto trên máy. Server tự khai schema lúc chạy. Công cụ debug mạnh nhất cho gRPC — nhưng nên tắt ở production nhạy cảm vì nó lộ toàn bộ API.
gRPC giữ kết nối lâu dài, nên load balancer tầng kết nối không rải được từng request — gRPC tự cân bằng ở phía client. Bài này chạy thật với 3 server: chính sách mặc định pick_first dồn cả 300 request vào một server (2 server ngồi không); đổi sang round_robin thì 300 request rải đều 100/101/99. Đo bằng counter thật mỗi server. Client biết danh sách backend qua resolver và tự chọn — không cần proxy ở giữa.
Cache nghe như giải pháp vạn năng cho hiệu năng, nhưng nhanh hơn bao nhiêu và khi nào mới đáng? Bài này đo thật: một query gộp 100.000 dòng trên PostgreSQL tốn 8.2ms mỗi lần tính; cache kết quả vào Redis thì GET chỉ 0.028ms (pipelined) hoặc 0.26ms (round-trip đơn) — nhanh hơn 30 đến 300 lần. Nhưng nói thẳng: với query đơn giản lấy một dòng theo khoá chính, chênh lệch nhỏ hơn nhiều. Cache thắng rõ khi tính toán gốc đắt.
Mười một phần qua ta mổ xẻ gRPC bằng demo đo thật. Bài cuối ghép lại: một service capstone gộp interceptor, deadline và error model cùng chạy; bảng tổng hợp mọi con số đo thật xuyên 12 bài (protobuf 26 vs JSON 70 byte, deadline huỷ 101ms, round_robin 100/101/99...); và khung quyết định gRPC vs REST — gRPC không tốt hơn, nó đánh đổi khác, hợp bài toán khác.