Số 421Quản lý Chất lượng

Twitter (2010–2013): tái kiến trúc sau World Cup 2010 và kỷ lục 143.199 tweet mỗi giây không gây sự cố

Trong World Cup 2010, Twitter liên tục sập vì lượng tweet tăng đột biến. Công ty quyết định lùi lại để tái kiến trúc: rời khối ứng dụng Ruby on Rails sang các dịch vụ chạy trên JVM, tách biệt để các đội phát hành độc lập. Tháng 8/2013, một buổi chiếu phim tại Nhật tạo đỉnh 143.199 tweet/giây — khoảng 25 lần mức bình thường — mà hệ thống vẫn ổn định. Bài học về đầu tư trả nợ kỹ thuật như một dự án có mục tiêu chất lượng.

Nguyễn Thu Hà, PMP

28/09/2026

2 phút đọc 0

Bình luận0

Bối cảnh thực tế

Những năm đầu, Twitter chạy trên một ứng dụng Ruby on Rails nguyên khối. Biểu tượng "cá voi thất bại" xuất hiện mỗi khi hệ thống quá tải trở nên quen thuộc với người dùng.

Theo bài viết của Raffi Krikorian, Phó chủ tịch kỹ thuật nền tảng của Twitter (8/2013):

Trong World Cup 2010, sự phấn khích của người hâm mộ khiến trang web sập thường xuyên. Sau đó công ty quyết định cần lùi lại và tái kiến trúc để hỗ trợ tăng trưởng.
Hướng đi: chuyển từ khối Ruby on Rails sang kiến trúc dịch vụ chạy trên JVM, với mục tiêu cải thiện hiệu năng và độ tin cậy, cô lập lỗi, và cho phép các đội phát triển, triển khai độc lập.
Ngày 3/8/2013 (giờ Nhật), khi truyền hình chiếu phim "Castle in the Sky", lưu lượng đạt đỉnh 143.199 tweet trong một giây — khoảng 25 lần mức trung bình khoảng 5.700 tweet/giây — và người dùng không gặp gián đoạn.

Phân tích nguyên nhân theo chuẩn PMP

Kiến trúc ban đầu là quyết định đúng ở quy mô nhỏ
Khối Rails giúp ra sản phẩm nhanh. Vấn đề là nợ kỹ thuật không được trả khi quy mô tăng nhiều bậc; yêu cầu phi chức năng (tải đỉnh, độ sẵn sàng) thay đổi nhưng kiến trúc thì không.
Sự kiện đỉnh là bài kiểm tra chất lượng có thể dự đoán
World Cup, lễ hội, sự kiện truyền hình là các đỉnh tải biết trước. Kế hoạch chất lượng phải gồm mục tiêu năng lực cho đỉnh, không chỉ trung bình.
Tái kiến trúc được định nghĩa bằng mục tiêu chất lượng
Dự án không chỉ "viết lại" mà có mục tiêu đo được: hiệu năng, độ tin cậy, cô lập lỗi, tốc độ phát hành. Đây là điều phân biệt tái kiến trúc thành công với việc viết lại không điểm dừng.

Twitter (2010–2013): tái kiến trúc sau World Cup 2010 và kỷ lục 143.199 tweet mỗi giây không gây sự cố

Bối cảnh thực tế

Phân tích nguyên nhân theo chuẩn PMP

Kiến trúc ban đầu là quyết định đúng ở quy mô nhỏ

Sự kiện đỉnh là bài kiểm tra chất lượng có thể dự đoán

Tái kiến trúc được định nghĩa bằng mục tiêu chất lượng

Cách làm đáng học và điều PM cần chuẩn bị

Bước 1: Biến nợ kỹ thuật thành business case

Bước 2: Chuyển dần theo từng dịch vụ

Bước 3: Đặt mục tiêu năng lực theo đỉnh

PM Takeaway (Bài học rút ra)

Nguồn tham khảo

Trắc nghiệm tình huống PMP

Bạn có 12 tháng trước một sự kiện đỉnh tải lớn và hệ thống nguyên khối đang quá tải. Bạn chọn gì?

Tình huống này hữu ích với bạn?

Bình luận (0)