Đặ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.
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.
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.
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ử.
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.
Redis xử lý lệnh trong phần trăm mili-giây, nhưng nếu client gửi từng lệnh một và chờ reply, phần lớn thời gian là chờ mạng (round-trip) chứ không phải Redis làm việc. Pipeline gộp nhiều lệnh vào một lần gửi để cắt số round-trip. Bài này đo thật trong redis-lab: cùng một kết nối, SET đạt 333.889 lệnh/giây ở P=1 nhưng 4.444.444 lệnh/giây ở P=50 — nhanh ~13 lần. Và pipeline khác transaction thế nào.