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.
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.
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.
HTTPS an toàn nhưng không miễn phí: sau bắt tay TCP, TLS thêm một bắt tay riêng tốn CPU (toán khóa công khai) và một RTT. Bài này chạy thật trong Go với self-signed cert: TLS full handshake tốn 391µs so với TCP thường 23µs — thêm ~368µs, phần lớn là CPU. Session resumption (500/500 kết nối resumed) bỏ phần đắt; giải thích vì sao trên localhost nó chỉ nhanh 1,1 lần còn trên mạng thực tiết kiệm cả một RTT.
Một primary PostgreSQL 16 và một streaming replica dựng bằng pg_basebackup. Lag đo bằng cách ghi rồi poll replica: p50 0,32 ms khi primary rảnh, 3,26 ms và p99 52,67 ms khi hai luồng chèn lô nền. Đọc ngay từ replica sau khi ghi: 500/500 lần không thấy, kể cả khi rảnh. Chữa phía đọc bằng cách chờ replica replay tới LSN của lần ghi: 0/500 — với điều kiện LSN lấy sau commit, lấy trong cùng câu INSERT thì vẫn 187/500 sai. Chữa phía ghi bằng synchronous_commit: remote_apply cho 0/300 với giá 0,24 so với 0,07 ms mỗi commit, và khi replica đồng bộ dừng, primary treo cho tới khi đổi tham số.