Real-time revenue analytics πάνω σε εκατομμύρια transactions/μέρα: πώς;

Question

IT Interview Practice · Accepted Answer

**Κάντε stream τα transactions μέσω Kafka σε έναν stream processor που κάνει pre-aggregate σε ένα OLAP store, ώστε τα dashboards να διαβάζουν μικροσκοπικά προ-υπολογισμένα rollups αντί να κάνουν scan τα raw events.** Σε εκατομμύρια txns/μέρα ποτέ δεν τρέχετε `SUM()` πάνω στον raw πίνακα σε κάθε φόρτωση σελίδας — κάνετε aggregate μία φορά, στο write.

## Αρχιτεκτονική

```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)
```

## Πώς λειτουργεί

- **Το Kafka** είναι το durable log. Κάθε πληρωμή δημοσιεύει ένα event (`amount`, `currency`, `ts`, `merchant`). Κάνει buffer τα spikes, αποσυζευγνύει τους producers από τους consumers, και σας αφήνει να κάνετε **replay** την ιστορία για να ξαναχτίσετε τα aggregates.
- **Ο stream processor (Flink / Kafka Streams)** κρατά **tumbling/sliding windows** (ανά λεπτό/ώρα) και διπλώνει κάθε event σε ένα running total στο **state store** του. Το output είναι μια προ-aggregated row ανά (λεπτό, dimension).
- **Το OLAP store (ClickHouse, Druid, Pinot)** αποθηκεύει αυτά τα rollups columnar. Ένα dashboard που κάνει query "έσοδα τελευταίων 24h" κάνει scan ~1.440 rows, όχι εκατομμύρια — sub-second.
- **Τα materialized views** στο ClickHouse μπορούν να κάνουν το ίδιο rollup μέσα στη βάση (`AggregatingMergeTree`) αν θέλετε λιγότερα κινούμενα μέρη.

## Οπτική συνέντευξης

Ο συνεντευκτής διερευνά αν κάνετε **pre-aggregate στο write vs scan στο read**, και αν καταλαβαίνετε το **exactly-once**. Καλές απαντήσεις κατονομάζουν Kafka + OLAP· εξαιρετικές απαντήσεις εξηγούν **γιατί τα late/duplicate events διαφθείρουν τα σύνολα** και πώς να τα διορθώσετε: idempotent keys, Flink **checkpointing + transactional sink** για exactly-once, και **watermarks** για να κλείνουν τα windows παρά τις καθυστερημένες αφίξεις. Μια συνηθισμένη παγίδα είναι να προτείνετε `SELECT SUM()` σε Postgres — μια χαρά σε χιλιάδες/μέρα, καταρρέει σε εκατομμύρια.

## Trade-offs & αποτυχία

- **Lambda vs Kappa.** Το Lambda τρέχει ένα batch layer (νυχτερινό Spark κάνει reconcile την πηγή αλήθειας) δίπλα στο stream layer (γρήγορο αλλά approximate) — ακριβές αλλά δύο codebases. Το **Kappa** χρησιμοποιεί μόνο το stream layer και **κάνει replay το Kafka** για να διορθώσει bugs — απλούστερο, ένα codebase, τώρα το συνηθισμένο default.
- **Το exactly-once δεν είναι δωρεάν.** Τα transactional sinks προσθέτουν latency και κόστος throughput· πολλές ομάδες αποδέχονται **at-least-once + idempotent upserts** με κλειδί το `txn_id` αντ' αυτού.
- **Late data.** Μια πληρωμή που εκκαθαρίζεται 2h αργά προσγειώνεται αφού έκλεισε το window της. Watermarks + allowed-lateness ξανα-ανοίγουν windows, ή ένα νυχτερινό batch job διορθώνει τα χθεσινά νούμερα.
- **Multi-currency / refunds** πρέπει να μοντελοποιηθούν ως signed events, αλλιώς τα "έσοδα" αποκλίνουν.
- **Πότε όχι:** μερικές χιλιάδες txns/μέρα δεν χρειάζονται τίποτα από αυτά — ένας Postgres rollup πίνακας ενημερωμένος από cron κερδίζει ένα Kafka+Flink cluster που πρέπει να λειτουργείτε.

Αρχιτεκτονική

Πώς λειτουργεί

Οπτική συνέντευξης

Trade-offs & αποτυχία

Σχετικές ερωτήσεις