Nếu chỉ được theo dõi một chỉ số của Kafka, hãy chọn consumer lag — khoảng cách giữa chỗ producer đã ghi và chỗ consumer đã xử lý. Bài này đo thật trong lab: lag phình từ 700 lên 1200 khi producer ghi nhanh hơn consumer, rồi co về 0 khi consumer đuổi kịp. Hiểu công thức LAG = LOG-END − CURRENT, phân biệt offset lag với time lag, và biết dấu hiệu nguy hiểm thật: lag tăng đều không ngừng.
Tracing chỉ ra chặng nào chậm; nhưng trong một chặng, HÀM nào ngốn CPU hay giữ RAM? Đừng đoán — pprof của Go đo trực tiếp. Bài này chạy thật runtime/pprof: CPU profile chỉ ra main.hotHash chiếm 100% CPU (qua sha256), heap profile chỉ ra main.allocBig giữ đúng 197.76MB còn allocSmall biến mất vì đã bị GC. Kèm cách đọc hai cột flat vs cum mà nhiều người nhầm.
cgo cho Go gọi hàm C, nhưng mỗi lần vượt biên giới Go↔C tốn một khoản phí cố định. Đo thật trong Go 1.23: một cgo call mất khoảng 22 ns dù hàm C rỗng hay có tính toán, gấp 95 lần một lời gọi Go — và cách gộp lô cứu được 76 lần.
Test ví dụ kiểm từng cặp input-output cụ thể; property-based testing khẳng định một tính chất đúng với mọi input rồi để máy sinh hàng vạn input tìm phản ví dụ. Đo thật trong Go với testing/quick: bất biến sắp xếp qua 100k input, và round-trip lộ bug logic khi list rỗng ra [0] — thứ fuzzing trần bỏ lọt.
WebSocket nâng cấp một kết nối HTTP thành kênh hai chiều mở liên tục cho chat, thông báo đẩy, dữ liệu real-time. Đo thật trong Go 1.23: bắt tay 101 Switching Protocols, gửi/nhận trên một kết nối bền, và một message qua WebSocket nhanh hơn HTTP polling khoảng 23 lần.
Độ bền của Kafka đến từ replication — mỗi partition có nhiều bản sao trên nhiều broker, với ISR là tập bản sao đang theo kịp. Bài này đo thật trên lab single-node và dùng chính các giới hạn làm bằng chứng: RF=1 chỉ có một bản sao, thử RF=2 báo lỗi vì chỉ một broker, và một phát hiện trung thực về min.insync.replicas mà single-node không tái hiện nổi. Hiểu RF, ISR, min.insync.replicas và acks=all để cấu hình độ bền đúng trên cluster thật.