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.

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

Tổng kết sê-ri gRPC: khi nào chọn gRPC thay REST, và checklist đưa service lên production đúc kết từ 11 bài

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.

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

Redis cho backend từ con số 0: vì sao một kho dữ liệu chạy MỘT luồng lại nhanh hơn 340.000 lệnh/giây

Redis nhanh một cách khó tin — hơn 340.000 lệnh mỗi giây, mỗi lệnh dưới một phần mười mili-giây. Điều nghịch lý: nó xử lý lệnh trên đúng MỘT luồng. Bài mở màn sê-ri dựng Redis thật trong Docker, đo throughput bằng redis-benchmark (SET 343.642/giây, GET 346.020/giây), giải thích ba lý do tốc độ (in-memory, single-thread không khoá, I/O đa hợp), và vì sao single-thread cũng chính là lý do mọi lệnh Redis nguyên tử.

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

Năm kiểu dữ liệu Redis: chọn đúng kiểu quyết định cả tốc độ lẫn bộ nhớ (leaderboard, bạn chung, và cái giá của sorted set)

Redis không phải chỉ là key-value string — nó có năm kiểu dữ liệu, mỗi kiểu giải một lớp bài toán. Bài này demo thật trong redis-lab cả năm: string/hash/list/set/sorted set, với use case thật (leaderboard bằng sorted set, bạn chung bằng SINTER một lệnh). Rồi đo MEMORY USAGE để thấy đánh đổi: hash 88 byte nhỏ hơn JSON 96 byte, nhưng sorted set tốn 87KB so với set 40KB cho cùng 1000 phần tử — cái giá của khả năng xếp hạng.