Incident Report: March 30th, 2026 — Authenticated user data cached

Railway · 2026 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Bối cảnh

• Trên Railway, CDN cache là opt-in: domain không bật CDN thì request luôn đi thẳng tới ứng dụng.
• Ngày 30/3/2026, 10:42–11:34 UTC (52 phút), một kỹ sư đẩy cấu hình mới cho nhà cung cấp CDN để bật Surrogate Keys (cache theo từng domain). Thay đổi này vô tình bật cache cho cả domain đã tắt CDN, khoảng 0,05% domain.

Chuyện gì xảy ra

• Response GET không có header cache tường minh bị cache mặc định, kể cả response của user đã đăng nhập (miễn không có Set-Cookie). Kết quả: user này có thể thấy trang dành cho user khác.
• Cache-Control từ origin vẫn được tôn trọng, và header Set-Cookie không bị cache. Ứng dụng nào ghi rõ header cache thì an toàn hơn.
• Timeline: 10:42 deploy → 11:14 phát hiện (tín hiệu nội bộ + báo cáo của user) → 11:34 revert xong và purge toàn bộ cache.

Khắc phục (theo Railway)

• Thêm test cho hành vi cache đúng/sai trước khi thay đổi lên production.
• Rollout CDN chia nhỏ theo shard trong nhiều giờ thay vì vài phút.
• Ưu tiên an toàn và bảo mật hơn tính năng mới trong giai đoạn tăng trưởng nóng.

Bài học cho SWE

• Lỗi cache nguy hiểm nhất không phải dữ liệu cũ mà là dữ liệu của người khác. Cache key thiếu danh tính user là rò rỉ dữ liệu (Cache và invalidation).
• Đừng dựa vào hạ tầng phía trước "mặc định không cache". Response cá nhân hoá nên tự ghi Cache-Control: private/no-store.
• Thay đổi cấu hình ở tầng edge có bán kính ảnh hưởng toàn cầu, nên cần rollout từ từ như code (Deploy và release an toàn).
• 32 phút từ deploy tới phát hiện: chưa có tín hiệu tự động cho "response bị cache sai" (Sự cố và postmortem).

Liên quan

• Railway 2026 (sự cố mạng cùng năm)
• Cache và invalidation · Sự cố và postmortem · Deploy và release an toàn