Inside Minerva: building scalable observability for eBay's monetization platform

eBay · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Hệ tính phí (monetization) của eBay phụ thuộc khoảng 200 thuộc tính của item, seller, marketplace, campaign; eBay báo Q2/2026 có 136 triệu buyer, 2,6 tỉ listing. Một tổng toàn cục có thể trông bình thường trong khi một site, loại phí hay khuyến mãi lệch; ngược lại một thay đổi đột ngột có thể hoàn toàn đúng (khuyến mãi hết hạn).
• Trước Minerva: dữ liệu warehouse (HDFS) về quá muộn để theo dõi một đợt rollout theo giờ, lại nằm ở vùng bảo mật khác; điều tra phải tự ghép từ nhiều nguồn; lỗi phí thường chỉ lộ ra qua khiếu nại khách hoặc phân tích sau giao dịch, tức sau vài giờ hay vài ngày.
• Ràng buộc: giám sát không được làm chậm hay làm mất ổn định service tính và thu phí.

Thay đổi chính

• Tách khỏi đường tính phí: service tính phí chỉ đặt một bản ghi nhỏ (định danh item và sự kiện tính phí) vào hàng đợi cục bộ; producer nền đẩy sang event stream. Request không chờ mạng, enrich hay ghi kho phân tích.
• Hàng đợi cục bộ giới hạn theo dung lượng và tuổi bản ghi; quá hạn thì xả hoặc ghi đè kiểu ring buffer thay vì phình vô hạn. Chủ ý ưu tiên độ sẵn sàng của tính phí hơn việc giám sát không mất dữ liệu: event stream không phải nguồn sự thật, mất một đoạn chỉ tạo khoảng trống giám sát.
• Enrich bất đồng bộ: consumer nền đọc read database giao dịch để lấy phí, listing, account, khuyến mãi; dữ liệu giám sát vì thế nhất quán sau (eventually consistent).
• Kho phân tích ClickHouse (bản ghi khoảng 250 cột, truy vấn chỉ đọc vài cột). PoC 1,1 tỉ dòng trên máy 6 vCPU, 44 GB: tra cứu và tổng hợp khoảng 0,11–0,72 giây; eBay tự ghi chú đây không phải benchmark production. Cân nhắc đặt bản ghi cùng seller/item trên cùng shard; chọn giữa làm phẳng (trùng ngữ cảnh) và chuẩn hoá (join lúc đọc). Minerva chỉ quan sát kết quả, không tính lại phí.
• Từ dữ liệu ra tín hiệu: ba module: chạy query theo lịch (nhiều instance phối hợp để mỗi query chỉ một instance chạy), xử lý use case (độ lệch phí, số giao dịch theo site/giờ, kết hợp phí với khuyến mãi để giải thích spike, gán mức độ), gửi thông báo theo kênh (PagerDuty, email, Slack; cấu hình chung rồi ghi đè theo luật hay theo phân đoạn dữ liệu).

Vì sao

• Gửi thẳng từ request tới stream từ xa sẽ ghép độ sẵn sàng của giám sát với độ sẵn sàng của tính phí: broker chậm hay backpressure làm tăng latency của đường thu tiền.
• Giám sát kinh doanh cần ngữ cảnh (thuộc tính gốc) để trả lời "đổi gì và vì sao", không chỉ tổng.

Bài học cho SWE

• Đưa telemetry ra khỏi đường nóng bằng hàng đợi cục bộ có giới hạn và chính sách bỏ rõ ràng; dữ liệu giám sát được phép mất, giao dịch thì không (Load shedding, rate limit và backpressure, Observability và monitoring).
• Gửi định danh rồi enrich phía sau giữ request nhẹ, đổi lại độ tươi (Event-driven, message queue và Kafka).
• Alert trên chỉ số kinh doanh theo từng phân đoạn bắt được lỗi mà tổng toàn cục che mất.

Liên quan

• Cùng công ty: eBay 2019 · eBay 2020
• Observability và monitoring · Load shedding, rate limit và backpressure · Event-driven, message queue và Kafka