রিপোর্ট এবং ML-এর জন্য একটি high-volume event-tracking পাইপলাইন ডিজাইন করুন — কোন স্ট্যাক?

Question

IT Interview Practice · Accepted Answer

প্রতিদিন কয়েকশো মিলিয়ন events/day (~কয়েক হাজার/sec, পিকে আরও বেশি)-এ বিজয়ী পদক্ষেপ হলো ingestion-কে serving থেকে decouple করা: একটি durable log-এ writes শোষণ করুন, স্ট্রিমটি একবার প্রসেস করুন, এবং বিপরীত কাজের জন্য টিউন করা দুটি store-এ fan out করুন — parents-এর জন্য pre-aggregated (fast reads), ML-এর জন্য raw এবং full-fidelity।

একটি mailroom — collector মেইল গ্রহণ করে, Kafka হলো conveyor belt, এবং প্রতিটি আইটেম দুটি shelf-এ কপি করা হয়: একটি যা parents একনজরে দেখে, এবং একটি যা ML টিম খুঁড়ে দেখে।

**মেন্টাল মডেল:** একটি mailroom — collector মেইল গ্রহণ করে, Kafka হলো conveyor belt, এবং প্রতিটি আইটেম দুটি shelf-এ কপি করা হয়: একটি *summary board* যা parents একনজরে দেখে, এবং একটি *full archive* যা ML টিম খুঁড়ে দেখে।

## Write path (ingest)

```text
Client ─(batch)─▶ Collector ─▶ Kafka ─▶ Stream proc ─┬─▶ OLAP rollup  (daily summaries)
 (learning app)    (HTTP)     (buffer,   (read once)  └─▶ S3 / Parquet (raw events)
                              replay)
```

- **Collector** HTTP-এর ওপর **batched** events গ্রহণ করে — ক্লায়েন্টে batching কয়েকশো মিলিয়ন ক্ষুদ্র writes-কে অনেক কম requests-এ পরিণত করে।
- **Kafka** হলো durable buffer: এটি spikes শোষণ করে, producers-কে consumers থেকে decouple করে, এবং ML যখন একটি feature যোগ করে বা আপনি একটি নতুন rollup চালু করেন তখন আপনাকে ইতিহাস **replay** করতে দেয়।
- **Stream processor** Kafka একবার পড়ে এবং উভয় sink-এ লেখে — lake-এ raw append করে, reports-এর জন্য rollups upsert করে।

```js
// একটি consumer Kafka একবার পড়ে এবং BOTH sinks-এ লেখে
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // raw -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// aggregate -> OLAP (reports)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Read path (serving)

```text
Parent app ─▶ API ─▶ OLAP rollup                 (pre-aggregated: report = O(1), no scan)
ML / Data  ─▶ Spark / warehouse ─▶ S3 / Parquet  (raw, flexible, ad-hoc)
```

Parents **pre-aggregated summaries**-এ হিট করে, তাই একটি report হলো একটি key lookup, কখনো বিলিয়ন rows-এর ওপর scan নয়। ML **raw lake** কোয়েরি করে, feature engineering-এর জন্য প্রতিটি field রেখে দেয়।

## Stack & why
- **Kafka** — buffer, decouple, replay।
- **ClickHouse / daily summary tables** — parent dashboards-এর জন্য read-optimized।
- **S3 + Parquet** — ML-এর জন্য সস্তা, columnar, flexible raw storage।
- **Schema registry** — event contract enforce করে যাতে producers নীরবে consumers ভাঙতে না পারে।

## Interview lens
ইন্টারভিউয়ার যাচাই করেন আপনি **write-optimized ingest-কে read-optimized serving থেকে আলাদা** করেন কিনা, প্রতিটি parent report-এর জন্য raw events scan করা এড়ান কিনা, এবং ML-এর জন্য raw data রাখেন কিনা। **দুর্বল:** "সবকিছু Postgres-এ রেখে কোয়েরি করুন।" **শক্তিশালী:** durable buffer + দুটি serving path + replay + একটি schema contract, স্কেল সম্পর্কে একটি feel সহ।

## Trade-offs
Pre-aggregation তাৎক্ষণিক reads দেয় কিন্তু dimensions আগে থেকে fix করে দেয়; raw lake flexible কিন্তু slow। **উভয়** রাখুন — ক্লাসিক write-once, read-many split।

Write path (ingest)

Read path (serving)

Stack & why

Interview lens

Trade-offs

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