Có lần team mình deploy bản mới lúc 11h đêm. kubectl rollout restart xong, 30 giây sau PagerDuty réo: 200 cái 502 trong 5 giây. Khách hàng đang đặt đồ ăn thì timeout. Mình lật đật rollout undo, xong ngồi check log — hóa ra pod cũ bị SIGTERM, HTTP server tắt ngay lập tức, 50 request đang xử lý dở bị cắt ngang hết.

Lỗi không phải ở Kubernetes. Lỗi ở service mình: không có graceful shutdown.

Tháng trước, một service của team mình đột nhiên chậm như rùa. p50 latency từ 50ms nhảy lên 3 giây. Mở Grafana lên — 120,000 goroutine đang chạy. Bình thường chỉ 200. Ai đó vừa push code quên defer cancel() trong một vòng lặp xử lý batch.

Goroutine là thứ làm Go ngon: nhẹ (~2KB stack), rẻ, bật cái là chạy. Nhưng chính vì quá dễ dùng nên quá dễ leak. Bài này là những pattern mình dùng để giữ goroutine trong tầm kiểm soát — từ errgroup đến worker pool đến backpressure. Tất cả có code chạy được, hầu hết rút từ production.

Năm đầu đi làm, mình từng viết một endpoint GET /api/menus trả về… toàn bộ menu. 200 items mỗi lần gọi. JSON nặng 1.2MB. Frontend chỉ cần tên + giá của 10 món đang active. Mình nhớ câu đầu tiên anh lead nói: “Mày đang gửi cả cái kho hàng cho người ta chỉ cần xem menu đấy à?”

Bài học đó mất 1 tuần refactor. Từ đó mỗi lần thiết kế API, mình luôn nghĩ đến quán cà phê: khách gọi iced Americano, barista không bưng ra cả quầy — họ ghi order rõ ràng, pha đúng món, và đưa đúng ly. API cũng phải vậy.

Hồi mới code Go, mình có một bug production kỳ lạ: cứ sau 3-4 ngày chạy, service tự dưng ngốn 8GB RAM rồi OOM. Mò suốt chiều thứ Sáu mới phát hiện: một cái goroutine không bao giờ kết thúc vì mình quên truyền context xuống gRPC call. Mỗi request leak một goroutine, sau 100K request thì server “đội mồ” luôn.

Đó là lần đầu mình hiểu context.Context không phải mấy dòng code cho có. Dùng sai là chết thật. Dùng đúng thì request dừng gọn, goroutine sạch, hệ thống nhẹ nhàng.