काफ्का इंटरव्यू में यह जांचा जाता है कि आप समझते हैं कि डेटा एक लॉग के ज़रिए कैसे आगे बढ़ता है: टॉपिक्स को पार्टीशन में कैसे बांटा जाता है, आप किस ऑर्डरिंग पर भरोसा कर सकते हैं, कंज़्यूमर आपस में काम कैसे बांटते हैं, और कुछ फेल होने पर क्या होता है। लैग, डुप्लीकेट और डेटा लॉस पर सिनेरियो-आधारित सवाल आम हैं, क्योंकि प्रोडक्शन में लोग इन्हीं दिक्कतों से टकराते हैं।
नीचे 22 सवाल उनके जवाबों के साथ दिए गए हैं। डिफ़ॉल्ट वैल्यू जैसी डिटेल्स काफ्का के वर्शन के हिसाब से बदलती रहती हैं, इसलिए यह ज़रूर बताएं कि आप इस्तेमाल हो रहे वर्शन को चेक करेंगे।
मुख्य अवधारणाएँ
1. काफ्का क्या है, और इसका इस्तेमाल किस लिए किया जाता है?
काफ्का एक डिस्ट्रीब्यूटेड, रेप्लिकेटेड कमिट लॉग है। प्रोड्यूसर टॉपिक्स में रिकॉर्ड जोड़ते हैं, और कंज़्यूमर अपनी रफ़्तार से उन्हें पढ़ते हैं। इसका इस्तेमाल इवेंट स्ट्रीमिंग, लॉग और मेट्रिक्स पाइपलाइन, सर्विसेज़ को एक-दूसरे से अलग (डिकपल) करने, एनालिटिक्स सिस्टम में डेटा भेजने और स्ट्रीम प्रोसेसिंग के लिए किया जाता है।
2. टॉपिक, पार्टीशन और ऑफ़सेट क्या हैं?
टॉपिक रिकॉर्ड्स की एक नामित स्ट्रीम है। हर टॉपिक को पार्टीशन में बांटा जाता है, और हर पार्टीशन एक ऑर्डर्ड, सिर्फ़ अपेंड-ओनली लॉग होता है। पार्टीशन में हर रिकॉर्ड का एक ऑफ़सेट होता है, यानी एक क्रमिक संख्या जो उसकी जगह बताती है। ऑफ़सेट सिर्फ़ उसी पार्टीशन के अंदर यूनीक होते हैं।
3. पार्टीशन ऑर्डरिंग को कैसे प्रभावित करते हैं?
काफ्का ऑर्डर की गारंटी सिर्फ़ एक पार्टीशन के अंदर देता है। एक ही की वाले रिकॉर्ड डिफ़ॉल्ट रूप से उसी पार्टीशन में जाते हैं, इसलिए वे एक-दूसरे के सापेक्ष अपने क्रम में रहते हैं। पार्टीशन के बीच कोई ऑर्डरिंग नहीं होती। अगर आपको एक कस्टमर के सारे इवेंट्स क्रम में चाहिए, तो कस्टमर ID को की बनाएं।
4. ब्रोकर क्या है, और कंट्रोलर क्या करता है?
ब्रोकर एक काफ्का सर्वर है जो पार्टीशन स्टोर करता है और क्लाइंट्स को सर्विस देता है। एक क्लस्टर में कई ब्रोकर होते हैं। इनमें से एक कंट्रोलर की तरह काम करता है, जो क्लस्टर मेटाडेटा और पार्टीशन लीडरशिप मैनेज करता है। नए काफ्का वर्शन में इस मेटाडेटा के लिए ZooKeeper की जगह KRaft इस्तेमाल होता है, जो एक बिल्ट-इन कंसेंसस मेकैनिज़्म है।
5. रेप्लिकेशन कैसे काम करता है?
हर पार्टीशन का एक रेप्लिकेशन फैक्टर होता है। एक रेप्लिका लीडर होती है, जो रीड और राइट संभालती है, और बाकी फॉलोअर होती हैं जो उसकी कॉपी करती हैं। इन-सिंक रेप्लिकाज़ (ISR) वे होती हैं जो लीडर के साथ अप-टू-डेट हैं। अगर लीडर फेल हो जाए, तो ISR में से नया लीडर चुना जाता है।
प्रोड्यूसर
6. acks सेटिंग्स का क्या मतलब है?
| acks | मतलब | ट्रेडऑफ़ |
|---|---|---|
| 0 | प्रोड्यूसर किसी भी पुष्टि का इंतज़ार नहीं करता | सबसे तेज़, डेटा लॉस हो सकता है |
| 1 | लीडर लिखने के बाद पुष्टि करता है | अगर लीडर रेप्लिकेट करने से पहले फेल हो जाए तो डेटा लॉस हो सकता है |
| all | लीडर सभी इन-सिंक रेप्लिकाज़ का इंतज़ार करता है | सबसे मज़बूत ड्यूरेबिलिटी, ज़्यादा लेटेंसी |
टिकाऊ राइट्स के लिए acks=all इस्तेमाल करें, साथ में min.insync.replicas कम से कम 2 रखें और रेप्लिकेशन फैक्टर 3 रखें।
7. प्रोड्यूसर से डुप्लीकेट मैसेज कैसे रोकें?
इडेम्पोटेंट प्रोड्यूसर चालू करें (enable.idempotence=true), जिससे ब्रोकर एक पार्टीशन के अंदर रीट्राई की वजह से बने डुप्लीकेट्स को हटा देता है। जिन राइट्स को कई पार्टीशन या टॉपिक में एक साथ एटॉमिक तरीके से करना हो, उनके लिए ट्रांज़ैक्शन इस्तेमाल करें।
8. प्रोड्यूसर पार्टीशन कैसे चुनता है?
अगर आप की देते हैं, तो डिफ़ॉल्ट पार्टीशनर उसे हैश करके पार्टीशन चुनता है। की न होने पर प्रोड्यूसर रिकॉर्ड्स को पार्टीशन्स में बांट देता है (हाल के वर्शन बैच कुशलता से भरने के लिए स्टिकी तरीका इस्तेमाल करते हैं)। आप कस्टम पार्टीशनर भी लिख सकते हैं।
9. प्रोड्यूसर थ्रूपुट को क्या प्रभावित करता है?
बैचिंग (batch.size, linger.ms), कम्प्रेशन (जैसे lz4 या zstd), पार्टीशन की संख्या, और acks। बड़े बैच और कम्प्रेशन आम तौर पर थ्रूपुट बढ़ाते हैं, लेकिन थोड़ी लेटेंसी के साथ।
उपभोक्ता
10. कंज्यूमर ग्रुप क्या है?
कंज्यूमर्स का एक समूह जो किसी टॉपिक को पढ़ने का काम आपस में बाँटता है। हर पार्टिशन एक समय में ग्रुप के एक ही कंज्यूमर को सौंपा जाता है। इसलिए किसी ग्रुप में उपयोगी कंज्यूमर्स की संख्या पार्टिशन की संख्या तक ही सीमित रहती है, और अतिरिक्त कंज्यूमर्स बेकार बैठे रहते हैं।
11. रीबैलेंस के दौरान क्या होता है?
जब कोई कंज्यूमर जुड़ता या हटता है, या पार्टिशन बदलते हैं, तो ग्रुप पार्टिशन दोबारा बाँट देता है। क्लासिक रीबैलेंस में इस दौरान कंजम्पशन रुक जाता है। कोऑपरेटिव रीबैलेंसिंग और स्टैटिक मेंबरशिप इस व्यवधान को कम करते हैं। बार-बार रीबैलेंस अक्सर उन कंज्यूमर्स की वजह से होता है जो प्रोसेसिंग में बहुत ज़्यादा समय लेते हैं (max.poll.interval.ms) या हार्टबीट मिस कर देते हैं।
12. ऑफसेट कैसे कमिट होते हैं?
कंज्यूमर्स अगले पढ़े जाने वाले रिकॉर्ड का ऑफसेट कमिट करते हैं, जो एक आंतरिक टॉपिक में सेव होता है। ऑटो-कमिट आसान है, लेकिन प्रोसेसिंग पूरी होने से पहले भी कमिट कर सकता है। प्रोसेसिंग के बाद मैन्युअल कमिट करने पर आपके हाथ में यह तय करने का नियंत्रण रहता है कि "पूरा होना" का मतलब क्या है।
13. at-most-once, at-least-once और exactly-once का क्या मतलब है?
- At-most-once: प्रोसेसिंग से पहले ऑफसेट कमिट करें। क्रैश होने पर रिकॉर्ड खो सकते हैं।
- At-least-once: पहले प्रोसेस करें, फिर कमिट करें। क्रैश होने पर रीप्रोसेसिंग हो सकती है, इसलिए डुप्लीकेट की संभावना रहती है।
- Exactly-once: असर सिर्फ़ एक बार होता है। Kafka में यह Kafka के अंदर ही मुमकिन है, idempotent producers, transactions और read_committed consumers की मदद से। जब किसी बाहरी सिस्टम में लिखना हो, तो आम तौर पर आपको idempotent writes या किसी key के आधार पर डीडुप्लीकेशन की ज़रूरत पड़ती है।
एक अच्छा जवाब यह बताता है कि "exactly once" इस पर निर्भर करता है कि साइड इफेक्ट्स कहाँ हो रहे हैं।
14. ऐसे पॉइज़न मैसेज को कैसे हैंडल करेंगे जो हमेशा फेल होता है?
एरर पकड़ें, सीमित बार रिट्राई करें, फिर रिकॉर्ड को डिटेल्स के साथ डेड-लेटर टॉपिक में भेज दें, ऑफसेट कमिट करें और आगे बढ़ते रहें। डेड-लेटर टॉपिक पर अलर्ट लगाएँ ताकि कोई जाँच करे।
ऑपरेशंस और परिदृश्य
15. कंज्यूमर लैग बढ़ता जा रहा है। आप इसका पता कैसे लगाएँगे?
- देखें कि किन पार्टिशन्स पर लैग है। सिर्फ़ एक पार्टिशन पर लैग होना skewed key की ओर इशारा करता है। हर जगह लैग होना धीमी प्रोसेसिंग या कम कंज्यूमर्स की ओर।
- हर रिकॉर्ड की प्रोसेसिंग का समय और डेटाबेस जैसी डाउनस्ट्रीम कॉल्स जाँचें।
- देखें कि बार-बार रीबैलेंस तो नहीं हो रहा।
- देखें कि प्रोड्यूसर रेट बढ़ा है या नहीं।
- इसे ज़्यादा कंज्यूमर्स (पार्टिशन काउंट तक), तेज़ प्रोसेसिंग, बैच हैंडलिंग या ज़्यादा पार्टिशन्स से ठीक करें।
16. पार्टिशन काउंट कब बढ़ाना चाहिए?
जब आपको मौजूदा कंज्यूमर्स से ज़्यादा पैरेललिज़्म चाहिए, या हर पार्टिशन का थ्रूपुट सीमा बन गया हो। सावधान रहें: पार्टिशन जोड़ने से नए रिकॉर्ड्स के लिए key-to-partition मैपिंग बदल जाती है, इसलिए किसी key का ऑर्डर इस बदलाव के आसपास टूट सकता है। जहाँ ऑर्डर मायने रखता है, वहाँ पार्टिशन काउंट की योजना पहले से बनाएँ।
17. डेटा कैसे रिटेन होता है, और लॉग कम्पैक्शन क्या है?
डिफ़ॉल्ट रूप से Kafka समय या साइज़ (retention.ms, retention.bytes) के आधार पर पुराने सेगमेंट्स हटा देता है। लॉग कम्पैक्शन के साथ, Kafka हर key के लिए कम से कम नवीनतम वैल्यू रखता है, जो चेंजलॉग या टेबल जैसे टॉपिक के लिए उपयुक्त है। null वैल्यू (tombstone) किसी key को डिलीशन के लिए मार्क करती है।
18. अगर कोई ब्रोकर फेल हो जाए तो क्या होता है?
उस ब्रोकर के नेतृत्व वाले पार्टिशन्स ISR में से नए लीडर चुन लेते हैं। क्लाइंट्स मेटाडेटा रीफ़्रेश करके आगे बढ़ते रहते हैं। अगर कोई in-sync replica उपलब्ध न हो, तो पार्टिशन अनुपलब्ध रहता है, जब तक आप unclean leader election की अनुमति न दें, जिसमें डेटा लॉस का जोखिम होता है।
19. Kafka क्लस्टर को सुरक्षित कैसे करेंगे?
ट्रांज़िट में एन्क्रिप्शन के लिए TLS, ऑथेंटिकेशन के लिए SASL (जैसे SCRAM या OAuth) या mutual TLS, टॉपिक्स और ग्रुप्स पर ऑथराइज़ेशन के लिए ACLs, और नेटवर्क कंट्रोल्स। ज़रूरत पड़ने पर संवेदनशील फ़ील्ड्स को एप्लिकेशन लेवल पर एन्क्रिप्ट करें।
20. Kafka की मॉनिटरिंग कैसे करेंगे?
मुख्य सिग्नल्स हैं कंज्यूमर लैग, under-replicated partitions, offline partitions, रिक्वेस्ट लेटेंसी, डिस्क उपयोग, और ISR के घटने-बढ़ने की दर, जो JMX मेट्रिक्स और Prometheus व Grafana जैसे टूल्स के ज़रिए इकट्ठा किए जाते हैं।
डिज़ाइन प्रश्न
21. RabbitMQ या SQS जैसी मैसेज क्यू के बजाय Kafka कब चुनेंगे?
Kafka तब चुनें जब आपको हाई थ्रूपुट, पुराने इवेंट्स का रीप्ले, एक ही स्ट्रीम के कई स्वतंत्र कंज्यूमर्स, या स्ट्रीम प्रोसेसिंग चाहिए। पारंपरिक क्यू तब चुनें जब per-message रूटिंग, साधारण टास्क क्यू चाहिए, या जब आप पार्टिशन्स मैनेज नहीं करना चाहते।
22. एक ऑर्डर इवेंट्स पाइपलाइन डिज़ाइन करें।
"ऑर्डर्स को orders टॉपिक पर भेजा जाता है, जिसे order ID से key किया जाता है ताकि किसी ऑर्डर के इवेंट्स क्रम में रहें। मैं तीन या ज़्यादा ब्रोकर्स, replication factor 3, acks=all, और idempotent producers इस्तेमाल करूँगा। बिलिंग, इन्वेंटरी और एनालिटिक्स के कंज्यूमर्स अपने-अपने ग्रुप इस्तेमाल करेंगे। बिलिंग की राइट्स order ID से idempotent होंगी, फेल रिकॉर्ड्स डेड-लेटर टॉपिक में जाएँगे, और मैं हर ग्रुप का लैग मॉनिटर करूँगा। पार्टिशन काउंट मैं पीक थ्रूपुट और अपेक्षित कंज्यूमर संख्या के आधार पर चुनूँगा, जिसमें बढ़ने की गुंजाइश हो।"
तैयारी कैसे करें
अगर संभव हो, तो लोकल Kafka चलाएँ, एक producer और एक consumer group लिखें, एक consumer बंद करें, और rebalance होते हुए देखें। जानबूझकर कुछ तोड़ें, जैसे कोई slow consumer, और lag देखें। अपनी हल की गई किसी data pipeline समस्या की एक असली कहानी तैयार रखें। संबंधित विषयों के लिए, हमारी Databricks और system design interviews गाइड देखें।
Delivery guarantees को ज़ोर से समझाने का अभ्यास करें, क्योंकि यहीं जवाब धुँधले पड़ जाते हैं। एक mock interview और transcript आपको दिखा देंगे कि कहाँ। किसी भी live interview में AI tools को लेकर employer के नियमों का पालन करें।
YesToTheOffer के साथ Kafka इंटरव्यू उत्तरों का अभ्यास करें
एक मॉक तकनीकी इंटरव्यू चलाएं, डिलीवरी गारंटी को जोर से समझाएं, और बाद में अपने ट्रांसक्रिप्ट की समीक्षा करें। 30 मुफ्त मिनट, कोई सदस्यता नहीं।
