दैनिक लाखौं transaction माथि real-time revenue analytics: कसरी?

Question

IT Interview Practice · Accepted Answer

**transaction लाई Kafka मार्फत एउटा stream processor मा stream गर्नुहोस् जसले OLAP store मा pre-aggregate गर्छ, ताकि dashboard ले कच्चा event scan नगरी सानो pre-computed rollup पढोस्।** दैनिक लाखौं txn मा तपाईं कहिल्यै प्रत्येक page load मा कच्चा table माथि `SUM()` चलाउनुहुन्न — तपाईं write मा एक पटक aggregate गर्नुहुन्छ।

## आर्किटेक्चर

```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** टिकाउ log हो। प्रत्येक payment ले एउटा event (`amount`, `currency`, `ts`, `merchant`) publish गर्छ। यसले spike buffer गर्छ, producer लाई consumer बाट decouple गर्छ, र aggregate पुनर्निर्माण गर्न इतिहास **replay** गर्न दिन्छ।
- **Stream processor (Flink / Kafka Streams)** ले **tumbling/sliding window** (प्रति मिनेट/घण्टा) राख्छ र प्रत्येक event लाई आफ्नो **state store** मा running total मा fold गर्छ। Output प्रति (मिनेट, dimension) एउटा pre-aggregated row हो।
- **OLAP store (ClickHouse, Druid, Pinot)** ले ती rollup लाई columnar भण्डारण गर्छ। "अन्तिम 24h revenue" query गर्ने dashboard ले लाखौं होइन, ~1,440 row scan गर्छ — sub-second।
- ClickHouse मा **Materialized view** ले कम चल्ने भाग चाहन्छ भने DB भित्रै त्यही rollup गर्न सक्छन् (`AggregatingMergeTree`)।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले तपाईंले **write मा pre-aggregate बनाम read मा scan** गर्नुहुन्छ कि, र **exactly-once** बुझ्नुहुन्छ कि probe गर्छन्। राम्रो उत्तरले Kafka + OLAP नाम दिन्छ; उत्कृष्टले **किन late/duplicate event ले total बिगार्छ** र कसरी सच्याउने भनेर व्याख्या गर्छ: idempotent key, exactly-once का लागि Flink **checkpointing + transactional sink**, र late arrival हुँदा पनि window बन्द गर्न **watermark**। एउटा साधारण जाल Postgres मा `SELECT SUM()` प्रस्ताव गर्नु हो — दैनिक हजारौंमा ठीक, लाखौंमा भत्किन्छ।

## ट्रेड-अफ र failure

- **Lambda बनाम Kappa.** Lambda ले stream layer (छिटो तर approximate) सँगै batch layer (रातको Spark ले सत्यको स्रोत reconcile गर्छ) चलाउँछ — सटीक तर दुई codebase। **Kappa** ले stream layer मात्र प्रयोग गर्छ र bug सच्याउन **Kafka replay** गर्छ — सरल, एउटै codebase, अहिले साधारण default।
- **Exactly-once मुफ्त छैन।** transactional sink ले latency र throughput लागत थप्छ; धेरै team ले बरु `txn_id` मा key गरिएको **at-least-once + idempotent upsert** स्वीकार्छन्।
- **Late data.** 2h ढिलो settle हुने payment window बन्द भएपछि पुग्छ। Watermark + allowed-lateness ले window पुनः खोल्छन्, वा रातको batch job ले हिजोको संख्या सच्याउँछ।
- **Multi-currency / refund** signed event को रूपमा model गर्नैपर्छ, नत्र "revenue" बहकिन्छ।
- **कहिले नगर्ने:** दैनिक केही हजार txn लाई यीमध्ये केही चाहिँदैन — cron ले update गर्ने Postgres rollup table ले तपाईंले चलाउनुपर्ने Kafka+Flink cluster लाई जित्छ।

आर्किटेक्चर

कसरी काम गर्छ

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure

सम्बन्धित प्रश्नहरू