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.
PostgreSQL 16, timing phía máy chủ: ADD COLUMN 7,6 ms, NOT NULL DEFAULT hằng 1,1 ms, DEFAULT now() 1,0 ms vì now() là stable, DEFAULT random() 739 ms viết lại 1 triệu dòng, SET NOT NULL trực tiếp 241 ms. Một giao dịch mở 8 giây cộng một ALTER vô hại làm tps đọc từ 80.000 về 0 trong 5 giây; lock_timeout 2 giây cắt tổn thất còn 2 giây. CREATE INDEX giữ ShareLock và chặn UPDATE 113 ms, CONCURRENTLY để UPDATE qua trong 1,6 ms. ADD CHECK trực tiếp dưới tải ghi mất 5 giây với ghi về 0, NOT VALID rồi VALIDATE không chặn giây nào. SET NOT NULL sau CHECK VALID còn 26 ms.
Cache-aside là pattern cache phổ biến nhất, nhưng nó có một lỗ hổng chết người: khi một key nóng hết hạn, mọi request đến cùng lúc đều miss và cùng đập vào database — cache stampede. Bài này đo thật trong redis-lab: cache HIT 1ms vs MISS 204ms; 20 client đồng thời khi key vắng gây 20 lần query DB; thêm một lock SET NX, số query DB giảm còn đúng 1. Hiểu để một đợt key hết hạn không kéo sập database.
O(n²) chậm hơn O(n log n) — ai cũng biết. Nhưng đo thật trong go-lab cho thấy nhiều thứ sách không nói: insertion sort O(n²) lại NHANH HƠN quicksort tự viết ở N=1.000; quicksort tự viết thua mergesort vì cấp phát bộ nhớ; và sort.Ints của thư viện chuẩn (introsort) đánh bại mọi bản tự viết. Cài đặt quan trọng ngang độ phức tạp.
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.
Báo cáo 'latency trung bình 0.133ms' nghe tuyệt — nhưng nó nói dối về trải nghiệm thật. Bài này đo thật 100.000 thao tác: p50 chỉ 0.003ms, mà p99 lên tới 6.121ms — mean giấu đuôi 46 lần, và 98% request thực ra nhanh hơn cả con số trung bình. Cách tính p50/p95/p99 bằng sort + nearest-rank, và vì sao SLO phải dùng percentile chứ không phải mean.