Khi append vượt cap, Go cấp mảng nền mới lớn hơn — nhưng nhân theo hệ số nào? Đo thật tiến trình cap: slice nhỏ nhân đôi (x2.00 tới cap 512), rồi giảm dần về ~1.25x cho slice lớn (1.66 1.51 1.40 1.33). Vì sao đổi hệ số và tại sao prealloc vẫn thắng. Go 1.23.
Khi map quá đầy, số bucket phải gấp đôi và mọi entry phải chuyển chỗ. Làm một lần sẽ khựng O(n). Đo thật: chèn 2 triệu entry, insert chậm nhất chỉ 0.6 ms — nhỏ hơn 330 lần so với 200 ms nếu chuyển hết một lần. Cơ chế evacuation tăng dần và load factor 6.5. Go 1.23.
Go dùng cú pháp assembly riêng kế thừa Plan 9, khó đọc lần đầu. Đọc thật assembly một hàm Go trên arm64 và amd64: thứ tự toán hạng nguồn-trước-đích-sau, bốn pseudo-register SB FP SP PC, và prologue kiểm tra stack qua thanh ghi g. Go 1.23.
Đọc một cấu hình chia sẻ hàng triệu lần bằng atomic.Pointer thay vì mutex. Đo thật: Load 0,082 ns so với RWMutex 71,6 ns khi đọc song song — nhanh hơn ~870 lần. Cách hot-swap nguyên tử, CompareAndSwap, và cạm bẫy kiểu của atomic.Value. Go 1.23.
Trace chẩn đoán một request; metrics trả lời hệ thống có khỏe không. Bài mổ xẻ ba loại metric Prometheus trong Go, vì sao histogram hơn hẳn trung bình, và đo thật chi phí: mọi thao tác 0 cấp phát, nhưng WithLabelValues tra cứu nhãn tốn 24 ns mỗi lần — cache handle về 1.7 ns.
Ở quy mô sharded, cần ID duy nhất mà không có điểm sinh trung tâm (nút thắt). Instagram gói vào 64 bit: 41 bit timestamp + 13 bit shard + 10 bit sequence, sinh ngay trong Postgres bằng PL/pgSQL. Bài này dựng THẬT đúng scheme đó: ID tăng theo thời gian, 50.000 ID không trùng, và trích được shard từ chính con số ID.