দিনে লক্ষ লক্ষ transaction-এর উপর real-time revenue analytics: কীভাবে?

Question

IT Interview Practice · Accepted Answer

**transaction-গুলোকে Kafka-এর মধ্য দিয়ে একটি stream processor-এ stream করুন যা একটি OLAP store-এ pre-aggregate করে, যাতে dashboard raw event scan করার বদলে ক্ষুদ্র pre-computed rollup পড়ে।** দিনে লক্ষ লক্ষ txn-এ আপনি কখনও প্রতিটি page load-এ raw 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** হলো durable log। প্রতিটি payment একটি event publish করে (`amount`, `currency`, `ts`, `merchant`)। এটি spike buffer করে, producer-কে consumer থেকে decouple করে, এবং aggregate পুনর্নির্মাণে history **replay** করতে দেয়।
- **Stream processor (Flink / Kafka Streams)** **tumbling/sliding window** (প্রতি মিনিট/ঘণ্টা) রাখে এবং প্রতিটি event-কে তার **state store**-এ একটি running total-এ fold করে। Output হলো প্রতি (minute, dimension)-এ একটি pre-aggregated row।
- **OLAP store (ClickHouse, Druid, Pinot)** সেই rollup-গুলো columnar সংরক্ষণ করে। "গত ২৪ঘ revenue" query করা একটি dashboard লক্ষ লক্ষ নয়, ~১,৪৪০ row scan করে — sub-second।
- ClickHouse-এ **Materialized view** DB-এর ভিতরেই একই rollup করতে পারে (`AggregatingMergeTree`) যদি আপনি কম moving part চান।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়ার যাচাই করেন আপনি **write-এ pre-aggregate বনাম read-এ scan** করেন কিনা, এবং আপনি **exactly-once** বোঝেন কিনা। ভালো উত্তর Kafka + OLAP নাম ধরে বলে; দারুণ উত্তর ব্যাখ্যা করে **কেন late/duplicate event total নষ্ট করে** এবং কীভাবে সেগুলো ঠিক করা যায়: idempotent key, exactly-once-এর জন্য Flink **checkpointing + transactional sink**, এবং late arrival সত্ত্বেও window বন্ধ করতে **watermark**। একটি সাধারণ ফাঁদ হলো Postgres-এ `SELECT SUM()` প্রস্তাব করা — দিনে হাজারে ঠিক, লক্ষে ধসে পড়ে।

## ট্রেড-অফ ও ব্যর্থতা

- **Lambda বনাম Kappa.** Lambda stream layer-এর (দ্রুত কিন্তু আনুমানিক) পাশে একটি batch layer (nightly Spark source of truth reconcile করে) চালায় — নির্ভুল কিন্তু দুটি codebase। **Kappa** কেবল stream layer ব্যবহার করে এবং bug ঠিক করতে **Kafka replay** করে — সরল, একটি codebase, এখন সাধারণ ডিফল্ট।
- **Exactly-once বিনামূল্যে নয়।** Transactional sink latency ও throughput খরচ যোগ করে; অনেক team বরং `txn_id`-তে key করা **at-least-once + idempotent upsert** মেনে নেয়।
- **Late data.** ২ঘ দেরিতে settle হওয়া একটি payment তার window বন্ধ হওয়ার পর নামে। Watermark + allowed-lateness window পুনরায় খোলে, বা একটি nightly batch job গতকালের সংখ্যা সংশোধন করে।
- **Multi-currency / refund** অবশ্যই signed event হিসেবে মডেল করতে হবে, নইলে "revenue" drift করে।
- **কখন নয়:** দিনে কয়েক হাজার txn-এর এসবের কিছুই লাগে না — একটি cron দিয়ে আপডেট করা একটি Postgres rollup table আপনাকে operate করতে হওয়া একটি Kafka+Flink cluster-কে হারায়।

আর্কিটেকচার

কীভাবে কাজ করে

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতা

সম্পর্কিত প্রশ্ন