# Revision: Cheat Sheet और Self-Check — Apache Kafka: बुनियाद से Production तक Event Streaming

Source: https://www.geekswithgeeks.com/hi/kafka/wrap-revision

> पूरे कोर्स की Kafka की अवधारणाओं, settings और संचालन आदतों की दोहराई करें।

## Cheat sheet

**मॉडल**: topic → partitions (क्रमबद्ध logs) → offsets; records में key/value/timestamp/headers; क्रम सिर्फ़ एक partition के भीतर। **Producers**: key → murmur2 % partitions; `acks=all`, idempotence, `linger.ms`, compression; registry के साथ schemas। **Consumers**: group = प्रति partition एक consumer; प्रोसेसिंग के बाद commit (at-least-once) और handlers idempotent बनाएँ; lag = log-end − committed; rebalances; poison records के लिए DLT। **Topics**: throughput से partitions का आकार (सिर्फ़ बढ़ सकते हैं; key मैपिंग बदलती है); retention बनाम compaction (tombstones); नामकरण और स्वामित्व। **Durability**: rf=3, `min.insync.replicas=2`, `acks=all`, कोई unclean चुनाव नहीं; Kafka के भीतर transactions से exactly-once। **Ecosystem**: Connect, Streams/Flink/ksqlDB। **संचालन**: lag, URP, disk, latency; TLS + SASL + ACLs; rolling upgrades; क्षमता = दर × retention × rf।

## इंटरव्यू में पूछे जाने वाले सवाल

इन्हें समझाने को तैयार रहें: Kafka में क्रम कैसे काम करता है और वह प्रति partition क्यों है, consumer group कैसे scale होता है, at-least-once का क्या मतलब है और प्रोसेसिंग को idempotent कैसे बनाते हैं, `acks`, replication factor और `min.insync.replicas` कैसे मिलते हैं, partitions जोड़ने पर क्या होता है, और बढ़ते consumer lag को कैसे debug करेंगे।

**Quiz:** Consumer lag बढ़ता जा रहा है। संभावित पहली जाँच कौन-सी है?

- [ ] क्या topics के नाम लंबे हैं
- [ ] क्या font पढ़ने योग्य है
- [x] क्या consumers धीमे या अटके हैं, या partitions/consumers कम हैं
- [ ] Topic हटाना

*Answer:* क्या consumers धीमे या अटके हैं, या partitions/consumers कम हैं. Lag तब बढ़ता है जब प्रोसेसिंग उत्पादन से धीमी हो, इसलिए consumer की गति, errors, rebalances और समानांतरता जाँचें।

**Quiz:** कौन-सा setup स्वीकृत writes खोए बिना एक broker विफलता सह लेता है?

- [x] rf=3, min.insync.replicas=2, acks=all
- [ ] rf=1, acks=1
- [ ] rf=2, min.insync.replicas=2, acks=all
- [ ] rf=3 के साथ acks=0

*Answer:* rf=3, min.insync.replicas=2, acks=all. तीन replicas में से दो in-sync ज़रूरी होने पर एक विफलता के बाद writes चलते हैं और डेटा दो brokers पर रहता है।

**Quiz:** आप चाहते हैं कि record दो बार पहुँचे तो भी प्रोसेसिंग सुरक्षित रहे। आप क्या करते हैं?

- [ ] ज़्यादा partitions जोड़ें
- [ ] प्रोसेसिंग से पहले commit करें
- [ ] Broker पर retries बंद करें
- [x] Handler को idempotent बनाएँ, जैसे अनोखी key से upsert

*Answer:* Handler को idempotent बनाएँ, जैसे अनोखी key से upsert. Idempotent handling दोहरा delivery हानिरहित बनाती है।