Check-in 50.000 người: giải phẫu một hệ thống không được phép sập

Hệ thống check-in sự kiện quy mô lớn phải giải ba bài toán cùng lúc: tải dồn cực đại trong thời gian ngắn, mạng hiện trường không ổn định, và không có cơ hội chạy lại. Bài viết mổ xẻ cách chúng tôi thiết kế cho cả ba — từ những sự kiện thật.

Vì sao check-in là bài toán khó hơn vẻ ngoài

Nhìn từ ngoài, check-in chỉ là quét mã và mở cổng. Nhìn từ trong, nó là bài toán tải có hình dạng ác mộng: 50.000 người không đến rải đều trong bốn tiếng — họ đến dồn trong 45 phút trước giờ diễn, nghĩa là hệ thống phải chịu đỉnh tải gấp nhiều chục lần mức trung bình, đúng vào lúc quan trọng nhất. Phần mềm văn phòng chậm hai giây không ai để ý; cổng check-in chậm hai giây nhân với hàng nghìn người là hàng chờ tràn ra đường và một ban tổ chức đang nhìn đồng hồ.

Quyết định thiết kế số một: giả định mạng sẽ chập chờn

Sân vận động và trung tâm hội nghị có một đặc điểm chung: hàng chục nghìn chiếc điện thoại cùng lúc biến mạng di động khu vực thành bãi lầy. Vì vậy nguyên tắc đầu tiên của chúng tôi nghe có vẻ ngược đời: hệ thống check-in tốt phải hoạt động được khi mất mạng. Mỗi cổng quét giữ bản sao danh sách vé tại chỗ, ghi nhận offline và tự đồng bộ khi mạng trở lại — kèm cơ chế phát hiện vé bị dùng hai lần ở hai cổng trong lúc mất kết nối. Đây là phần khó nhất của cả bài toán, và là phần không bao giờ xuất hiện trong bản demo bán hàng của bất kỳ ai.

Quyết định số hai: load-test theo kịch bản xấu nhất, không phải kịch bản đẹp

Trước mỗi sự kiện lớn, chúng tôi bắn tải giả lập theo đúng hình dạng thật của dòng người — cả cú sốc 45 phút vàng — chứ không phải tải rải đều dễ chịu. Con số 99,9% uptime của nền tảng không đến từ may mắn; nó đến từ việc mọi sự cố đều đã xảy ra trước, trong môi trường thử.

Quyết định số ba: phòng điều hành nhìn thấy hiện trường theo giây

Với ban tổ chức, màn hình đáng giá nhất không phải tổng số đã check-in — mà là tốc độ dòng chảy từng cổng ngay lúc này. Cổng 3 đang nghẽn? Điều nhân sự sang trước khi hàng chờ thành vấn đề, không phải sau. Dashboard thời gian thực biến đội vận hành từ chữa cháy thành điều phối.

Bài học chuyển được sang ngành khác

Ba nguyên tắc trên — thiết kế cho đỉnh tải thay vì trung bình, giả định hạ tầng không hoàn hảo, cho người vận hành thấy hiện trường theo thời gian thực — áp dụng cho mọi hệ thống "một lần chạy phải đúng": bán vé mở màn, flash sale, đăng ký tuyển sinh. Nếu hệ thống của bạn có một "giờ G" như vậy, đó là ba câu hỏi đầu tiên nên đặt cho đơn vị xây nó.

Nền tảng sự kiện của Code4Change đang phục vụ 1.000+ doanh nghiệp, sự kiện lớn nhất 50.000 người. Sự kiện của bạn có giờ G sắp tới? Trò chuyện với kỹ sư — miễn phí.