प्रतिदिन करोड़ों events (~कुछ हज़ार/सेकंड, peaks पर अधिक) पर जीतने वाली चाल है ingestion को serving से decouple करना: writes को एक durable log में सोखें, stream को एक बार process करें, और विपरीत कामों के लिए tuned दो stores में fan out करें — parents के लिए pre-aggregated (तेज़ reads), ML के लिए raw और full-fidelity।
एक mailroom — collector डाक प्राप्त करता है, Kafka conveyor belt है, और हर आइटम दो shelves पर कॉपी होता है: एक जिसे parents एक नज़र देखते हैं, और एक जिसे ML टीम खंगालती है।
Client ─(batch)─▶ Collector ─▶ Kafka ─▶ Stream proc ─┬─▶ OLAP rollup (daily summaries)
(learning app) (HTTP) (buffer, (read once) └─▶ S3 / Parquet (raw events)
replay)
// एक ही consumer Kafka को एक बार पढ़ता है और दोनों 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();
}
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 को query करता है, feature engineering के लिए हर field रखता है।
इंटरव्यूअर परखता है कि क्या आप write-optimized ingest को read-optimized serving से अलग करते हैं, हर parent report के लिए raw events scan करने से बचते हैं, और ML के लिए raw data रखते हैं। कमज़ोर: "सब कुछ Postgres में डालो और query करो।" मज़बूत: durable buffer + दो serving paths + replay + एक schema contract, scale की समझ के साथ।
Pre-aggregation तुरंत reads देता है पर dimensions पहले से तय कर देता है; raw lake flexible पर धीमा है। दोनों रखें — क्लासिक write-once, read-many विभाजन।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें