Trong hệ phân tán, code cũ và mới chạy song song lúc triển khai — dữ liệu phải đọc chéo được cả hai chiều. Bài này chạy thật bằng Protobuf: code mới ghi 4 field, code cũ đọc vẫn lấy được 2 field và bỏ qua field lạ không crash; code cũ ghi 2 field, code mới đọc field mới nhận default. Và một cái bẫy đo được: đổi kiểu field làm mất dữ liệu âm thầm. Kèm luật an toàn vs nguy hiểm.
gRPC không phải REST nhanh hơn — nó là một mô hình khác: định nghĩa dịch vụ trong .proto, protoc sinh code type-safe cho cả server lẫn client, chạy trên HTTP/2 với payload nhị phân Protobuf. Bài mở màn sê-ri dựng server+client gRPC thật bằng Go trong Docker, gọi một unary RPC, và đo thật: cùng message Order, Protobuf 41 byte so với JSON 88 byte, 1000 call hết 42ms (~23.800 call/giây localhost).
Protobuf nhỏ hơn JSON không phải nhờ phép màu — mà nhờ ba quyết định thiết kế gọn gàng. Bài này dùng proto.Marshal rồi hexdump từng byte trong go-lab để giải mã: mỗi field là một tag (field_number dịch bit cộng wire_type) rồi tới value, số nguyên mã hoá bằng varint (số nhỏ chỉ 1 byte), và field mang giá trị mặc định không được ghi lên dây chút nào. Kết quả thật: cùng dữ liệu, JSON 46 byte còn Protobuf 13 byte, message rỗng tốn 0 byte.
REST chỉ có một kiểu: một request, một response. gRPC có bốn, nhờ HTTP/2 cho phép streaming hai chiều ngay trong contract. Bài này chạy thật cả bốn trong go-lab: unary Double(21) trả 42; server streaming CountUp(5) trả về 5 message; client streaming SumAll gửi 4 nhận 1 (total=100); bidirectional RunningSum gửi/nhận xen kẽ 3 lần. Chỉ cần thêm từ khoá stream vào .proto, và biết khi nào dùng kiểu nào.
Protobuf nhận diện field bằng SỐ chứ không bằng tên — hiểu điều này là hiểu toàn bộ quy tắc tiến hoá schema. Bài này đo thật trong go-lab ba kịch bản: V1 ghi, V2 (thêm field) đọc được, field mới lấy default; V2 ghi có email, service V1 cũ đọc không thấy nhưng GIỮ LẠI email qua round-trip nhờ unknown field; và đổi field number khiến amount biến mất hoàn toàn. Rút ra luật quan trọng nhất của Protobuf.
Mười một bài, hàng chục phép đo thật — giờ gộp lại thành quyết định dùng được. Bài tổng kết này so gRPC với REST và GraphQL để biết khi nào chọn cái nào, một cây quyết định có nên dùng gRPC không, và một checklist đưa service gRPC lên production ánh xạ về từng bài: contract-first, field number bất biến, deadline, interceptor, status code, TLS, streaming đúng chỗ, load balancing, health check, graceful shutdown.