प्रॉम्प्ट और संदर्भ
जब कोई tenant बंद होता है, तो सिस्टम को एक deletion request मिलती है। Tenant का डेटा एक primary database, object storage, search indexes, caches, और backups में फैला होता है। डिलीशन को न तो request thread को ब्लॉक करना चाहिए और न ही तब चुपचाप काम खोना चाहिए जब कोई downstream अनुपलब्ध हो। इंटरव्यू का फोकस orchestration, idempotency, recovery, और "complete" स्टेट के पीछे के प्रमाण पर है।
इंटरव्यूअर क्या टेस्ट कर रहा है
इंटरव्यूअर यह देखना चाहता है कि कॉम्पोनेंट बनाने से पहले deletion semantics परिभाषित की जाएं। एक मजबूत डिज़ाइन में data catalog, state machine, task partitioning, idempotency keys, retries और dead letters, concurrency control, observability, और अंतिम प्रमाण शामिल होते हैं। Object-storage डॉक्युमेंटेशन immediate deletion, versions, और lifecycle rules के बीच अंतर करता है; replicas और asynchronous deletion का मतलब है कि primary-database की सफलता यह प्रमाण नहीं है कि हर कॉपी प्रोसेस हो चुकी है।
पहले पूछने वाले क्लेरिफाइंग प्रश्न
यह पूछें कि स्कोप एक tenant के लिए है, एक user के लिए है, या चुने हुए resources के लिए; hard delete, delayed delete, और retention windows कैसे परिभाषित हैं; backups तुरंत मिटाए जाते हैं या एक विंडो के बाद expire होते हैं; raw personal data कॉपी किए बिना कौन से audit records बने रहने चाहिए; और consistency, completion-time, scale, और policy boundaries क्या लागू होती हैं। ऐसी कोई legal deadlines न बनाएं जो दी नहीं गई हों।
30 सेकंड का उत्तर फ्रेमवर्क
कहें: "मैं एक tenant data catalog और deletion policy बनाऊंगा, फिर storage adapters के ज़रिए versioned deletion jobs को ऑर्केस्ट्रेट करूंगा। Request एक idempotent job बनाती है और जल्दी वापस आती है; एक queue phases को चलाती है, और हर phase evidence, retries, और अपनी last error रिकॉर्ड करती है। Verifier job को तभी complete मार्क करता है जब primary data, derived indexes, caches, और policy-allowed backups अपनी states पूरी करते हैं; अन्यथा यह retry या human handling शेड्यूल करता है।"
चरण-दर-चरण गहन विश्लेषण
1. Data Catalog और Policy बनाएं
हर resource record के लिए tenant ownership, location, derivation, deletion method, retention window, और verification query दर्ज करें। जो backups या logs तुरंत डिलीट नहीं किए जा सकते, उन्हें policy exceptions के रूप में चिह्नित करें, जिसमें expiry, approval, और यह शामिल है कि retention के दौरान वे product reads के लिए कैसे अनुपलब्ध रहते हैं।
2. एक Idempotent Deletion Job सबमिट करें
Close flow एक globally unique deletionJobId बनाता है और idempotency condition के रूप में tenant generation या closure-event version का उपयोग करता है। API एक accepted status जल्दी लौटाती है; duplicate requests वही job लौटाती हैं। Catalog version का एक snapshot persist करें ताकि बाद के catalog edits job boundary न बदलें।
3. Retryable काम को Dependency के अनुसार विभाजित करें
पहले writes को freeze करें या tenant state बदलें, फिर primary records और objects प्रोसेस करें, उसके बाद search indexes, caches, और derived files। हर adapter (deletionJobId, resourceId, generation) को अपनी idempotency key के रूप में उपयोग करता है। Success, already-absent, और safely retryable errors के लिए अलग-अलग outcomes की ज़रूरत है; non-retryable errors को human recovery path के साथ dead-letter queue में भेजा जाता है।
4. Replicas, Versions, और Backups को हैंडल करें
Object storage में versions, lifecycle rules, और cross-region replicas हो सकती हैं; एक सफल delete API call यह साबित नहीं करती कि asynchronous copies तुरंत हट गई हैं। हर replica के लिए request time, observed version या delete marker, और last check रिकॉर्ड करें। Backups को उनकी retention policy से गुज़रने दें और expiry के बाद irrecoverability verify करें, न कि यह दिखावा करें कि erasure तात्कालिक है।
5. Verifier और Completion States डिज़ाइन करें
Verifier catalog को query करता है और primary reads, index searches, cache reads, और object listings चेक करता है। State machine को कम से कम ACCEPTED, RUNNING, WAITING_RETRY, BLOCKED, VERIFIED, और FAILED के बीच अंतर करना चाहिए। केवल required resources जिनके पास evidence और explicit policy exceptions हों, VERIFIED तक पहुंच सकते हैं; conditional writes एक पुरानी retry को नए result को overwrite करने से रोकते हैं।
6. Observability, Isolation, और Audit जोड़ें
Tenant और job के अनुसार latency, success rate, retries, dead letters, downstream throttling, और remaining resources को ट्रैक करें। Cross-tenant deletion रोकने के लिए dedicated credentials और least privilege का उपयोग करें। Audit records में केवल job ID, resource type, policy version, actor, और result summary रखें, कभी raw data नहीं। Alerts एक blocked tenant को global downstream outage से अलग पहचानें।
उच्च-गुणवत्ता वाला सैंपल उत्तर
"मैं tables, object prefixes, indexes, cache keys, और backup policies के एक catalog से शुरू करूंगा, जिनमें से हर एक में tenant ownership, एक deletion method, और एक verification query होगी। किसी tenant को बंद करने पर एक unique deletionJobId लिखा जाता है, new writes freeze हो जाती हैं, और job enqueue हो जाती है। Orchestrator dependencies का पालन करता है: पहले primary data और objects, फिर indexes और caches; हर adapter resource generation के अनुसार idempotent है। Replica और object-version evidence रिकॉर्ड किया जाता है, जबकि backups अपनी retention policy का पालन करते हैं न कि तुरंत मिटाया गया दावा किया जाता है। एक verifier primary, search, cache, और object listings को फिर से चेक करता है और VERIFIED तब ही जाता है जब हर required resource का evidence मौजूद हो। Downstream failures exponential backoff और फिर एक named owner के साथ dead-letter path का उपयोग करती हैं। Audits policy version, result summary, और job ID स्टोर करते हैं; credentials tenant-isolated हैं। Client को queryable status और evidence मिलता है, न कि बिना समर्थन वाली 'deleted' string।"
सामान्य गलतियाँ और सुधार
- केवल primary rows डिलीट करना: Data catalog और derivations बनाएं, फिर हर एक के लिए deletion और verification परिभाषित करें।
- हर downstream को synchronously कॉल करना: Request latency को outages से अलग करने के लिए job queue और state machine का उपयोग करें।
- Duplicate काम को exception मानना: Per-resource idempotency key परिभाषित करें और already-absent को failure से अलग पहचानें।
- Instant backup erasure का वादा करना: Retention window, lifecycle, और verifiable expiry state बताएं।
फॉलो-अप प्रश्न और उत्तर
जब कोई downstream बार-बार fail होता रहे तो client को क्या दिखना चाहिए?
Internal credentials expose किए बिना queryable job state, phase, error class, और next retry time लौटाएं। Retry budget खत्म होने के बाद BLOCKED या FAILED पर जाएं, owner को notify करें, और एक safe resume path बनाए रखें।
आप एक पुरानी job को नई writes डिलीट करने से कैसे रोकते हैं?
Writes freeze करें या tenant generation का उपयोग करें। हर delete में creation के समय capture की गई generation होती है, और storage condition mismatch होने पर reject कर देती है। Catalog और status updates भी versioned conditional writes का उपयोग करते हैं।
आप कैसे टेस्ट करते हैं कि VERIFIED false positive नहीं हो सकता?
Duplicate messages, delayed replicas, index rebuilds, cache repopulation, और backup restores inject करें। अगर एक simulated query अभी भी डेटा पढ़ सकती है, तो verifier को incomplete रहना चाहिए और missing evidence रिकॉर्ड करनी चाहिए।
अगर audit logs में खुद tenant की जानकारी हो तो?
केवल एक irreversible tenant reference या hash, job ID, policy version, और result summary स्टोर करें। Access restrict करें और audit record को उसकी अपनी retention policy दें। Auditing को deleted data कॉपी किए बिना processing का प्रमाण देना चाहिए।