Tổng hợp lượt click quảng cáo

1) Người xem bấm quảng cáo và được chuyển tới trang đích

Click đi qua redirect service của ta thay vì nhảy thẳng tới trang đích, nên không phụ thuộc JavaScript phía client hay trình chặn quảng cáo. Service chỉ xác minh token và ghi sự kiện, việc đếm làm phía sau.

1. 1Ad server sinh link /c/{token}, token ký HMAC chứa impression_id, ad_id, thời điểm hiển thị
2. 2Người xem bấm, redirect service kiểm tra chữ ký và hạn của token
3. 3Service tra URL đích của ad_id trong cache cục bộ, trả 302
4. 4Sự kiện click được gửi vào queue (Kafka ở mức lớn) với key ad_id; token sai thì vẫn redirect nhưng ghi cờ không hợp lệ

Nguồn: Grokking Modern System Design · ch.34 TinyURL ↗ · mục "Requirements" (redirect phải sẵn sàng cao vì lỗi redirect là lỗi người dùng thấy) ; Grokking Modern System Design · ch.17 Distributed Messaging Queue ↗ · bài "Design of a Distributed Messaging Queue" (producer ghi vào queue) ; Chưa có nguồn trong thư viện: token ký HMAC là kỹ thuật bảo mật cơ bản, thư viện không bàn

2) Số click được tổng hợp gần real-time

Tầng stream đọc sự kiện, loại trùng theo click_id, áp luật gian lận cơ bản, rồi đếm theo cửa sổ 1 phút cho mỗi ad_id dựa trên thời điểm click (event time).

1. 1Flink đọc topic clicks, key theo click_id để loại trùng trong keyed state 24 h
2. 2Áp luật: quá nhiều click từ một IP hoặc thiết bị, click ngay sau hiển thị dưới 100 ms, user agent bot
3. 3Key lại theo ad_id, đếm theo cửa sổ tumbling 1 phút với watermark
4. 4Ghi (ad_id, phút, clicks, valid_clicks) vào kho OLAP, ghi đè được nếu cửa sổ tính lại

Nguồn: Microservices Patterns ↗ (.zip) · ch.3 · §3.3.6 Handling duplicate messages (tr. 95–96) (track messages and discard duplicates theo message id) ; Chưa có nguồn trong thư viện: thư viện không có sách về Flink/Spark/ClickHouse/Kafka; chỉ nêu khái niệm cơ bản (event time, watermark, cửa sổ tumbling)

3) Nhà quảng cáo xem số liệu theo thời gian

Truy vấn luôn đọc bảng đã tổng hợp sẵn, không bao giờ đọc click thô. Kho OLAP giữ bảng phút và các bảng giờ, ngày gộp sẵn, phân vùng theo ngày và sắp theo advertiser_id.

1. 1Dashboard gọi /v1/advertisers/{id}/clicks với khoảng thời gian
2. 2Query API chọn bảng theo độ chi tiết: ≤ 2 ngày dùng bảng phút, ≤ 90 ngày dùng bảng giờ, dài hơn dùng bảng ngày
3. 3Kết quả cache 30 s trong Redis theo (advertiser, truy vấn)
4. 4Khoảng đã đối soát lấy số batch, khoảng hôm nay lấy số stream và gắn nhãn tạm tính

Nguồn: Grokking Modern System Design · ch.21 Distributed Search ↗ · mục "Indexing" (dữ liệu tổng hợp sẵn phục vụ truy vấn nhanh) ; Grokking Modern System Design · ch.16 Distributed Cache ↗ · mục "Writing policies" ; Chưa có nguồn trong thư viện: kho OLAP và chọn bảng theo độ chi tiết là thiết kế của khoá học

4) Số tính tiền được chốt mỗi ngày

Click thô được lưu nguyên vào data lake. Mỗi đêm job batch tính lại toàn bộ ngày hôm trước với luật loại trùng và gian lận đầy đủ, so với số stream và thay thế phân vùng ngày đó.

1. 1Kafka Connect đổ topic clicks vào S3 dạng Parquet theo giờ
2. 2Spark đọc cả ngày, loại trùng theo click_id, áp luật gian lận cả ngày
3. 3So từng ad_id với số stream, ghi ReconciliationReport, cảnh báo nếu lệch > 0,1%
4. 4Ghi đè phân vùng ngày trong kho OLAP bằng số batch, đánh dấu đã chốt

Nguồn: Grokking Modern System Design · ch.21 Distributed Search ↗ · mục "Scaling Search and Indexing" (MapReduce xử lý hàng loạt trên cụm phân tán) ; Chưa có nguồn trong thư viện: thư viện không có sách về Flink/Spark/ClickHouse/Kafka; chỉ nêu khái niệm cơ bản (Spark, Parquet, đối soát)

1) Ghi nhận click thế nào để không mất click mà redirect vẫn nhanh?

2) Tổng hợp gần real-time thế nào, nhất là với click đến muộn?

3) Loại click trùng và click gian lận thế nào?

4) Trả số liệu theo nhà quảng cáo nhanh và khớp với số tính tiền thế nào?