Tối ưu hóa API lịch sử sao (star history): Từ 2.500 request xuống còn 24

Đối với các nhà phát triển và duy trì dự án (maintainer), việc theo dõi lịch sử số lượng sao (star) là cách quan trọng để đánh giá hiệu quả của các đợt phát hành hoặc sự kiện truyền thông. Trước đây, để xây dựng biểu đồ này, các công cụ phải truy vấn danh sách chi tiết từng người dùng đã gắn sao, sau đó lọc lấy dấu thời gian và loại bỏ danh tính. Cách làm này không chỉ gây lãng phí tài nguyên mà còn tạo lỗ hổng để kẻ xấu thu thập dữ liệu nhằm mục đích spam hoặc phishing.

Vấn đề từ thiết kế cũ

API cũ GET /repos/{owner}/{repo}/stargazers vốn được thiết kế để trả về danh sách người dùng, không phải là một nhật ký sự kiện lịch sử. Khi một repository có hàng trăm nghìn sao, việc truy vấn dữ liệu này trở nên cực kỳ tốn kém. Một lỗi trong cơ chế phân trang (pagination) khiến hệ thống phải đếm toàn bộ số sao hiện có cho mỗi request, dẫn đến hàng nghìn truy vấn chậm và gây quá tải cho database.

Giải pháp: Tập trung vào xu hướng, không phải danh tính

GitHub đã quyết định thay đổi cách tiếp cận bằng việc ra mắt endpoint mới chuyên biệt cho lịch sử sao. Thay vì trả về danh sách người dùng, API mới cung cấp số lượng sao theo ngày trong khoảng thời gian lên tới 30 tuần chỉ trong một request duy nhất.

Điểm mấu chốt trong việc tối ưu hóa hiệu suất nằm ở thứ tự xử lý dữ liệu:

• Lọc trước khi đếm: Thay vì truy vấn toàn bộ dữ liệu rồi mới nhóm (group) và phân trang, API mới áp dụng bộ lọc theo phạm vi thời gian (indexed date range) ngay từ đầu.
• Giảm tải database: Với cách làm này, mỗi request chỉ xử lý dữ liệu trong khoảng thời gian được yêu cầu thay vì quét toàn bộ lịch sử của repository. Kết quả là với các dự án lớn như react/react, số lượng request cần thiết đã giảm từ khoảng 2.511 xuống chỉ còn 24.

Bài học kinh nghiệm

Thông qua quá trình này, đội ngũ kỹ thuật của GitHub rút ra những bài học quan trọng về kiến trúc hệ thống:

• Phản hồi nhỏ không đồng nghĩa với truy vấn rẻ: Việc sử dụng LIMIT và OFFSET không giúp ích nếu database vẫn phải thực hiện các thao tác nhóm và sắp xếp trên toàn bộ tập dữ liệu trước đó.
• Tập trung vào nhu cầu thực tế: Khi hiểu rõ mục đích của người dùng là theo dõi xu hướng thay vì danh tính, việc thiết kế API trở nên đơn giản và an toàn hơn.
• Nguyên tắc tối thiểu dữ liệu: Chỉ trả về những gì cần thiết để tránh rủi ro lộ lọt thông tin cá nhân.

Việc thay đổi này không chỉ giúp bảo vệ quyền riêng tư của người dùng mà còn giúp API trở nên ổn định, tiết kiệm tài nguyên hơn cho cả GitHub và các nhà phát triển công cụ bên thứ ba.

Nguồn tham khảo: GitHub Blog