Thống kê doanh thu real-time trên hàng triệu giao dịch/ngày: làm sao?

Question

IT Interview Practice · Accepted Answer

**Đẩy giao dịch qua Kafka vào một stream processor để pre-aggregate sẵn vào OLAP store, nhờ đó dashboard đọc các rollup đã tính sẵn thay vì quét toàn bộ event thô.** Ở mức hàng triệu txn/ngày, bạn không bao giờ chạy `SUM()` trên bảng thô mỗi lần load trang — hãy tổng hợp một lần, ngay lúc ghi.

## Kiến trúc

```text
Payment svc ──▶ Kafka topic ──▶ Flink/Kafka Streams ──┬─▶ OLAP (ClickHouse/Druid)  ◀── Dashboard
 (txn events)   (buffer,replay)   (windowed pre-agg)    │      (per-minute rollups)     (read)
                                                         └─▶ S3/Parquet (raw, replay/audit)
                                     state store ◀──────────┘  (exactly-once checkpoints)
```

## Cách hoạt động

- **Kafka** là log bền. Mỗi lần thanh toán phát một event (`amount`, `currency`, `ts`, `merchant`). Nó đệm các đợt spike, tách producer khỏi consumer, và cho phép **replay** lịch sử để dựng lại aggregate.
- **Stream processor (Flink / Kafka Streams)** giữ các **window tumbling/sliding** (theo phút/giờ) và cộng dồn từng event vào tổng chạy trong **state store**. Đầu ra là một dòng đã pre-aggregate theo (phút, chiều dữ liệu).
- **OLAP store (ClickHouse, Druid, Pinot)** lưu các rollup đó theo cột. Dashboard hỏi "doanh thu 24h qua" chỉ quét ~1.440 dòng, không phải hàng triệu — dưới một giây.
- **Materialized view** trong ClickHouse có thể rollup ngay trong DB (`AggregatingMergeTree`) nếu bạn muốn ít thành phần phải vận hành hơn.

## Góc nhìn phỏng vấn

Người phỏng vấn dò xem bạn có phân biệt **pre-aggregate lúc ghi vs quét lúc đọc** không, và có hiểu **exactly-once** không. Câu trả lời khá gọi tên Kafka + OLAP; câu xuất sắc giải thích **vì sao event trễ/trùng làm sai tổng** và cách chữa: idempotent key, Flink **checkpointing + transactional sink** cho exactly-once, và **watermark** để đóng window dù có event tới trễ. Bẫy hay gặp là đề xuất `SELECT SUM()` trên Postgres — ổn ở mức vài nghìn/ngày, sập ở mức hàng triệu.

## Đánh đổi & lỗi

- **Lambda vs Kappa.** Lambda chạy một batch layer (Spark ban đêm đối soát nguồn sự thật) song song với stream layer (nhanh nhưng gần đúng) — chính xác nhưng hai codebase. **Kappa** chỉ dùng stream layer và **replay Kafka** để sửa bug — đơn giản, một codebase, nay là lựa chọn mặc định phổ biến.
- **Exactly-once không miễn phí.** Transactional sink thêm latency và tốn throughput; nhiều team chấp nhận **at-least-once + idempotent upsert** theo khoá `txn_id` thay vì vậy.
- **Dữ liệu trễ.** Một khoản settle trễ 2h rơi vào sau khi window đã đóng. Watermark + allowed-lateness mở lại window, hoặc một job batch ban đêm chỉnh lại số của hôm qua.
- **Đa tiền tệ / hoàn tiền** phải mô hình hoá thành event có dấu, nếu không "doanh thu" sẽ lệch.
- **Khi nào không dùng:** vài nghìn txn/ngày thì chẳng cần gì trong số này — một bảng rollup Postgres cập nhật bằng cron thắng hẳn một cụm Kafka+Flink mà bạn phải vận hành.

Kiến trúc

Cách hoạt động

Góc nhìn phỏng vấn

Đánh đổi & lỗi

Câu hỏi liên quan