- Chuyển cảnh sang Netflix, một tối thứ Bảy, lượng người xem tăng vọt từ 1 triệu lên 5 triệu người trên toàn cầu vì một bộ phim hot vừa ra mắt. Nếu hệ thống không mở rộng được, bạn sẽ chỉ thấy vòng xoay “buffering” đáng ghét.
- Netflix làm thế nào? Họ dùng hệ thống phân tán (distributed system) trên đám mây, với các máy chủ đặt ở nhiều khu vực – từ Mỹ, châu Âu đến châu Á. Khi lượng người xem tăng, Netflix tự động phân phối nội dung từ máy chủ gần bạn nhất, đồng thời tăng tài nguyên cho khu vực có nhu cầu cao. Nhờ vậy, bạn vẫn xem phim 4K mượt mà, dù cả thế giới cùng “cày” phim.
3/ RỒI THÌ GRAB VÀ GIỜ TAN TẦM BÃO TỐ
- Đến với Grab tại Việt Nam, vào giờ tan tầm, lượng đơn hàng tăng gấp 3 lần – từ 50.000 lên 150.000 đơn mỗi giờ. Nếu hệ thống không mở rộng được, bạn sẽ phải chờ mãi mà không có tài xế. Grab đã chuẩn bị bằng cách dùng kiến trúc microservices – chia nhỏ hệ thống thành các phần độc lập như đặt xe, thanh toán, và định vị.
- Khi lượng đơn tăng, họ chỉ cần “bơm” thêm tài nguyên cho phần đặt xe, mà không cần nâng cấp toàn bộ hệ thống. Kết quả? Bạn vẫn có xe đón đúng giờ, dù cả thành phố cùng gọi Grab.
4/ PHÂN BIỆT SCALABILITY VÀ PERFORMANCE: ĐỪNG NHẦM LẪN!
- Bạn có thể thắc mắc: “Scalability nghe giống Performance quá, phải không?” Mình cũng từng nghĩ vậy, nhưng thực ra chúng khác nhau rõ rệt. Performance (Hiệu suất) là về tốc độ và hiệu quả ngay bây giờ: hệ thống chạy nhanh thế nào với lượng người dùng hiện tại? Ví dụ: Shopee tải trang trong 2 giây với 10.000 người dùng, hay Grab tìm tài xế trong 5 giây với 50.000 đơn hàng.
- Còn Scalability (Khả năng mở rộng) là về tương lai: hệ thống có thể xử lý bao nhiêu người dùng hơn nữa nếu nhu cầu tăng? Ví dụ: Grab có thể tăng từ 50.000 lên 150.000 đơn mà không sập. Nói cách khác, Performance là “hệ thống chạy tốt thế nào hôm nay”, còn Scalability là “hệ thống có thể lớn hơn bao nhiêu ngày mai”. Hiểu rõ sự khác biệt này giúp bạn tránh nhầm lẫn khi làm việc với các yêu cầu hệ thống.
5/ MÌNH VIẾT YÊU CẦU SCALABILITY CHI TIẾT THẾ NÀO?
Là một Business Analyst, mình luôn phải viết yêu cầu Scalability rõ ràng để đội kỹ thuật hiểu và triển khai đúng. Dưới đây là cách mình viết yêu cầu chi tiết cho các ví dụ trên, và bạn cũng có thể áp dụng cách trình bày này:
- Zoom: “Hệ thống phải có khả năng mở rộng để xử lý từ 10.000 lên 100.000 cuộc họp đồng thời trong vòng 5 phút khi nhu cầu tăng, với thời gian thêm tài nguyên (scaling time) dưới 30 giây, sử dụng cloud infrastructure (AWS). Đo lường bằng load test với 100.000 người dùng giả lập.”
- Netflix: “Hệ thống phải mở rộng để hỗ trợ từ 1 triệu lên 5 triệu người xem đồng thời trong giờ cao điểm, đảm bảo không tăng độ trễ streaming quá 5% (tối đa 1 giây buffering), sử dụng hệ thống phân tán trên đám mây. Đo lường bằng stress test với 5 triệu luồng stream giả lập.”
- Grab: “Hệ thống phải mở rộng để xử lý từ 50.000 lên 150.000 đơn hàng mỗi giờ trong giờ cao điểm, với thời gian tìm tài xế không tăng quá 10% (tối đa 5,5 giây), sử dụng kiến trúc microservices và auto-scaling. Đo lường bằng load test với 150.000 đơn hàng giả lập.”
Hướng dẫn trình bày:
Khi viết yêu cầu Scalability, bạn cần:
- (1) Xác định mức tăng trưởng (từ bao nhiêu lên bao nhiêu)
- (2) Đưa ra tiêu chí đo lường (thời gian, độ trễ)
- (3) Nêu công nghệ sử dụng (cloud, microservices)
- (4) Đề xuất cách kiểm tra (load test, stress test). Cách viết này giúp yêu cầu rõ ràng, đo lường được, và dễ triển khai.
6/ KINH NGHIỆM BỎ TÚI CỦA MÌNH LÀ
Khi làm việc với Scalability, mình luôn phải nghĩ xa: “Hệ thống sẽ thế nào nếu lượng người dùng tăng gấp 10 lần?” Đầu tiên, mình hỏi khách hàng: “Bạn kỳ vọng hệ thống xử lý bao nhiêu người? Bao nhiêu giao dịch trong tương lai?” – ví dụ, 5 triệu người xem Netflix hay 150.000 đơn Grab mỗi giờ.
Sau đó, mình đề xuất cách kiểm tra: dùng load test để mô phỏng lượng truy cập tăng đột biến, xem hệ thống có “sống sót” không. Cuối cùng, mình phối hợp với đội kỹ thuật, đảm bảo họ thiết kế hệ thống với khả năng auto-scaling, như dùng đám mây hoặc microservices.
7/ TỔNG KẾT LẠI
Scalability là “lá chắn” giúp hệ thống không sụp đổ khi nhu cầu bùng nổ. Zoom, Netflix, Grab – họ thành công vì đã chuẩn bị cho những ngày “cả thế giới cùng nhấn nút”.
Là Business Analyst, mình học được rằng: không có hệ thống nào “nhỏ mãi”, và nếu không nghĩ đến mở rộng, bạn sẽ mất khách hàng ngay khi họ cần bạn nhất. Lần tới khi bạn xem phim hay gọi xe, hãy nhớ: Có cả một đội ngũ đang “bơm sức” để hệ thống không sập!
Bài này tiếp nối Series Non-Functional Requirement P2. Bạn nào chưa đọc phần trước thì tìm đọc lại cho đầy đủ nghen. Have a nice day!
