डेटा इंजीनियर इंटरव्यू सवाल

क्या Kafka में exactly once delivery सचमुच मुमकिन है, और व्यवहार में आप उसे कैसे हासिल करेंगे?

इंटरव्यूअर असल में क्या परख रहा है, अपना जवाब कैसे स्ट्रक्चर करें, और एक बोला हुआ उदाहरण जिसे आप अपना सकते हैं।

छोटा जवाब

नेटवर्क के आर पार exactly once delivery मुमकिन नहीं है, लेकिन exactly once processing एक हद तक मुमकिन है। Kafka आपको idempotent producer और transactions देता है, इसलिए Kafka के अंदर एक read process write चक्र offsets और output दोनों को atomically commit करता है। पूरे सिरे तक पहुंचने के लिए sink का साथ देना जरूरी है, या तो transactional write से या किसी स्थिर key पर idempotent upsert से। असल में ज्यादातर टीमें at least once के साथ idempotent sinks पर टिकती हैं।

इंटरव्यूअर यह क्यों पूछते हैं

यह distributed systems पर आपकी सोच की गहराई जांचता है। कमजोर जवाब enable.idempotence बराबर true कहकर रुक जाते हैं। इंटरव्यूअर delivery और processing का फर्क सुनना चाहते हैं, Kafka transactions की सीमा भी (वे सिर्फ Kafka topics और consumer offsets को कवर करते हैं), और यह व्यावहारिक सच्चाई भी कि पूरे सिरे तक पाइपलाइन को सही idempotent sinks ही बनाते हैं।

अपना जवाब कैसे स्ट्रक्चर करें

  • exactly once delivery को exactly once processing से अलग करें।
  • idempotent producer समझाएं और बताएं वह कौन सा duplicate हटाता है।
  • बताएं कि transactions output और offset commit दोनों को atomically कैसे ढकते हैं।
  • सीमा साफ कहें: external sinks transaction के अंदर नहीं आते।
  • व्यावहारिक जवाब पर उतरें: at least once के साथ idempotent writes।

उदाहरण जवाब

बोला हुआ उदाहरण, पहले व्यक्ति में

सख्ती से कहें तो नहीं। भरोसेमंद न होने वाले नेटवर्क पर exactly once delivery की गारंटी नहीं दी जा सकती, क्योंकि acknowledgment हमेशा खो सकता है और भेजने वाले को दोबारा भेजने या छोड़ देने में से एक चुनना ही पड़ता है। Kafka जो देता है वह है Kafka के अंदर exactly once processing semantics। idempotent producer एक producer id और sequence number जोड़ता है ताकि दोबारा भेजा गया send partition पर duplicate न बनाए, और transactions आपको अपने output records और consumer offsets एक साथ atomically commit करने देते हैं, इसलिए read process write topology फेल होने पर दोहरी गिनती नहीं करती। सीमा दायरे की है। जिस पल आप Postgres या S3 पर लिखते हैं, वह write transaction के बाहर है। इसलिए मैं असल में जो बनाता हूं वह है at least once delivery के साथ idempotent sink, आम तौर पर event id या natural key पर merge। एक clickstream पाइपलाइन पर हमने सात दिन की window के साथ event_id पर dedupe किया, जो हर hop को transactional बनाने की कोशिश से सस्ता भी था और समझने में आसान भी।

जल्दी ही यह इंटरव्यू देने जा रहे हैं? GhostPilot आपकी लाइव कॉल सुनता है, सवाल पूछे जाते ही उसे पकड़ लेता है, और रियल-टाइम में एक स्ट्रक्चर्ड जवाब आपकी स्क्रीन पर डाल देता है। अगले मॉक में इसे आजमाएं, या ले लें एक $29 Session Pass, कोई सब्सक्रिप्शन नहीं, असली इंटरव्यू के लिए।

देखें यह कैसे काम करता है

फॉलो-अप सवाल जिनकी उम्मीद रखें

  • transactional.id क्या करता है और restart पर वह क्यों मायने रखता है?
  • बिना असीमित state रखे किसी stream को आप कैसे deduplicate करेंगे?
  • transactions चालू करने की performance कीमत क्या है?

डेटा इंजीनियर के और सवाल

आपका इंटरव्यूअर इसका अपना वर्ज़न पूछेगा। फ्री Question Predictor में अपना असली जॉब डिस्क्रिप्शन पेस्ट कीजिए और वो 20 सवाल पाइए जो उस रोल में सबसे ज्यादा पूछे जाने की संभावना है, साथ में यह भी कि हर सवाल असल में क्या टटोल रहा है।

मेरे सवाल प्रेडिक्ट करें

मुश्किल सवाल पूछे जाने से पहले उनकी रिहर्सल कीजिए

एक लाइव कोपायलट के साथ प्रैक्टिस कीजिए, फिर तैयार होकर अंदर जाइए। $29 Session Pass आपको इंटरव्यू पार करा देता है, न कोई सब्सक्रिप्शन, न कोई लॉक-इन।

GhostPilot पाएं