Backend & APICâu hỏi đầu tiên không phải chọn giao thức mà là: người gọi có cần kết quả ngay mới đi tiếp được không?
Đồng bộ (REST / gRPC) — cần kết quả để xử lý tiếp: kiểm tra tồn kho trước khi tạo đơn, xác thực token. Đổi lại, người gọi phụ thuộc tính sẵn sàng của người bị gọi và cộng dồn latency.
Bất đồng bộ (message / event) — không cần kết quả ngay: gửi email xác nhận, cập nhật số liệu, đồng bộ sang search index. Người gọi ghi message rồi trả về ngay; broker giữ message nên bên nhận chết tạm thời cũng không mất việc. Đổi lại: eventual consistency, phải xử lý trùng message (idempotent) và cần DLQ cho message hỏng.
REST và gRPC khi đã chọn đồng bộ:
| REST/JSON | gRPC | |
|---|---|---|
| Payload | Text, tự mô tả | Protobuf nhị phân, nhỏ và nhanh hơn |
| Hợp đồng | OpenAPI (tuỳ chọn) | .proto bắt buộc, sinh code hai đầu |
| Streaming | Hạn chế | Hỗ trợ hai chiều sẵn |
| Dùng từ trình duyệt | Trực tiếp | Cần gRPC-Web/proxy |
Thực tế hay gặp: REST cho API ra ngoài / cho frontend, gRPC cho gọi nội bộ giữa service (nhất là chặng gọi nhiều, cần latency thấp và hợp đồng chặt), message cho mọi việc chạy nền và cho phát tán sự kiện tới nhiều bên.
Bẫy hay bị hỏi thêm: chuỗi gọi đồng bộ dài (A→B→C→D) làm độ sẵn sàng nhân với nhau và lỗi lan ngược. Nếu thấy chuỗi dài, cân nhắc chuyển các chặng không cần kết quả ngay sang bất đồng bộ.