A postmortem of our May 7, 2026 outage

Coinbase · 2026 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bối cảnh

Tối 7/5/2026 (19:20 ET): nhiều máy làm lạnh hỏng cùng lúc trong một data hall của AWS us-east-1 (AZ use1-az4). Rack tự tắt vì nhiệt, kéo theo EC2 và EBS trong toà nhà đó. Nhiều công ty khác cũng bị ảnh hưởng.
Theo Coinbase, đây đúng là loại lỗi mà nguyên tắc "mất trọn một AZ vẫn phải chạy" sinh ra để chịu.
Hậu quả: giao dịch, nạp, rút gián đoạn khoảng 8 giờ, mất thêm khoảng 12 giờ mới hồi phục hoàn toàn.
- 19:48 gần như toàn bộ giao dịch dừng;
- matching engine mở lại ở chế độ chỉ-huỷ-lệnh lúc 2:25, giao dịch đầy đủ lúc 3:49 ngày 8/5;
- app và web hồi phục hoàn toàn 9:53; backlog event stream hết lúc 14:00.

Hai kiểu lỗi, mỗi cái đều tự khôi phục được, nhưng cộng dồn thì kéo dài.

Matching engine dồn vào một toà nhà. Cụm Raft 5 node chạy trong một Cluster Placement Group, chọn có chủ đích: theo Coinbase, latency và throughput của một sàn khớp lệnh không chịu được việc các node bỏ phiếu phải nói chuyện xuyên AZ. Nhưng họ không có failover tự động sang AZ khác.
- 21:29 AWS tắt EC2 trong placement group: 3/5 node chết, mất quorum.
- Khôi phục cần sửa code khẩn trong sự cố (bỏ giả định lúc khởi động rằng cả 5 node đều phân giải được), dựng node group mới ngoài placement group, ghép lại quorum 3/5. Có quorum lúc 0:06; mở chợ theo thứ tự: chỉ-huỷ → đấu giá → giao dịch đầy đủ.
Kafka managed (MSK) hỏng âm thầm. Lẽ ra mất một AZ chỉ là giảm năng lực, nhưng lỗi ở control plane của MSK làm không bầu lại leader partition được. Hai cụm kẹt ở trạng thái "healing", producer không ghi được.
- Dây chuyền: fee service tắc → báo giá tắc. Khách thấy "giao dịch và báo giá hỏng" chứ không thấy "Kafka hỏng". Ledger, thanh toán, data pipeline cũng dính.
- Một cụm chỉ cấu hình 2 AZ làm tăng phạm vi ảnh hưởng, dù lỗi MSK tác động như nhau lên cụm 2 và 3 AZ.
- Cùng kỹ sư AWS, họ dời partition bằng tay lúc 3:00; topic ưu tiên 0 và 1 hồi phục lúc 9:30.

Matching engine có warm standby xuyên AZ; diễn tập failover trên production định kỳ (sàn lớn nhất trong cửa sổ bảo trì, còn lại trên sandbox).
Kafka: tìm gốc lỗi cùng AWS; tool, runbook, test cho các kiểu lỗi đã gặp và cho những điều khiển Kafka mà MSK không cho; chuyển cụm 2 AZ sang 3 AZ.
Theo Coinbase: "tiêu chuẩn của chúng tôi không phụ thuộc AWS có sự cố hay không".

Tối ưu latency bằng co-location (placement group, một toà nhà) là đánh đổi trực tiếp với khả năng chịu mất AZ. Đã chọn vậy thì phải có failover sang chỗ khác đã được diễn tập (Độ tin cậy và multi-region).
Giả định lúc khởi động ("mọi node đều tồn tại") là kiểu giới hạn ẩn chỉ lộ khi khôi phục.
Dịch vụ managed cũng có control plane hỏng được: "managed" không có nghĩa là tự chữa lành. Cần runbook cho cả lỗi của nhà cung cấp.
Thêm một ví dụ cho mẫu "nhiều lỗi nhỏ, mỗi cái tự khôi phục được, nhưng cộng dồn thành sự cố dài" (Sự cố và postmortem).