Lập trình 22/09/2026 5 phút

Deadline và context trong gRPC: hạn chót lan truyền cả chuỗi gọi, và server dừng sớm để không phí tài nguyên

Một request không bao giờ nên treo vô hạn. gRPC gắn deadline vào context, gửi kèm request, để mọi tầng biết còn bao lâu và dừng đúng lúc. Bài này đo thật trong go-lab: call deadline 100ms vào handler làm 500ms trả về sau đúng 100ms với code DeadlineExceeded (không chờ hết việc); và server đọc ctx.Done() để dừng sớm thay vì chạy nốt 500ms vô ích. Hiểu cơ chế này để chống quá tải lan rộng.

Lập trình 22/09/2026 5 phút

Xử lý lỗi trong gRPC: status code chuẩn và rich error details — để client xử lý đúng thay vì đoán chuỗi

Trả lỗi bằng một chuỗi text buộc client phải đoán và regex — mong manh và dễ vỡ. gRPC có bộ status code chuẩn hoá (NotFound, InvalidArgument, Unavailable...) để client rẽ nhánh đúng, và rich error details để gửi lỗi CÓ CẤU TRÚC. Bài này đo thật trong go-lab: Get id không tồn tại trả NotFound, id âm trả InvalidArgument; và Create với input xấu trả về danh sách field vi phạm (email, age) để client đọc type-safe thay vì parse câu lỗi.

Lập trình 22/09/2026 5 phút

Metadata và xác thực trong gRPC: truyền token như header HTTP, kiểm auth một chỗ cho mọi RPC

gRPC không có khái niệm header riêng — nó dùng metadata, cặp key-value gửi kèm mỗi request giống HTTP header. Bài này đo thật trong go-lab: client gắn token qua metadata.AppendToOutgoingContext, server đọc trong một interceptor auth tập trung. Gọi không token trả Unauthenticated, token sai trả PermissionDenied, token đúng mới cho handler chạy và server lấy được user=alice từ token. Và vì sao metadata bắt buộc chạy trên TLS.

Lập trình 22/09/2026 6 phút

Hiệu năng streaming gRPC: vì sao một stream nhanh gấp 61 lần 50.000 unary call, và flow control giữ cho khỏi tràn

Khi cần gửi nhiều message, chọn một stream hay nhiều unary call tạo ra khác biệt khổng lồ. Bài này đo thật trong go-lab: gửi 50.000 message qua 50.000 unary call riêng lẻ mất 2,06 giây (24k msg/s), còn qua một server-stream chỉ 33,6 mili-giây (1,49 triệu msg/s) — nhanh gấp 61 lần. Giải thích vì sao per-call overhead giết hiệu năng, và HTTP/2 flow control điều tiết backpressure thế nào để stream không làm tràn bộ nhớ.

Lập trình 22/09/2026 5 phút

Load balancing phía client trong gRPC: vì sao LB kiểu HTTP/1 dồn hết vào một server, và round-robin chia đều thế nào

Đặt một load balancer thường trước gRPC là một bẫy: vì gRPC giữ một kết nối HTTP/2 lâu dài, LB mức kết nối (L4) ghim mọi request vào đúng một backend. Bài này đo thật trong go-lab: chạy 3 server, dùng client-side round-robin, gọi 300 RPC — chia gần như hoàn hảo 100/99/101 giữa ba server. Hiểu vì sao gRPC cần cân tải ở mức RPC (client-side hoặc proxy L7), không phải mức kết nối.

Lập trình 22/09/2026 5 phút

gRPC cho production: health check, reflection và graceful shutdown — ba thứ không có khi học nhưng bắt buộc khi chạy thật

Một service gRPC chạy được chưa phải chạy được trong production. Bài này đo thật trong go-lab ba tính năng vận hành: health check để orchestrator biết pod sống hay chết (SERVING và NOT_SERVING đổi được), server reflection để grpcurl liệt kê service mà không cần file .proto, và graceful shutdown để khi deploy không rớt request đang chạy — GracefulStop chờ request 800ms hoàn thành nhưng từ chối request mới ngay.