01एक फ़ाइल अधिकतम कितनी बड़ी हो सकती है?
उपयोगकर्ता किसी भी device से upload और download करते हैं, फ़ाइलें 50 GB तक।
मुफ़्त पूरी गाइड
फाइल सिंक सिस्टम
फाइल सिंक सिस्टम डिज़ाइन करें। इसमें File chunking strategy and content-hash based deduplication across users, Delta sync: rsync-style block diffing instead of re-uploading whole files, Metadata...
00
अभ्यास checkpoints
Interview की लय संक्षिप्त रहती है, ताकि page असली design निर्णयों पर ध्यान लगा सके.
- 01Scope स्पष्ट करें
- 02Requirements + scale
- 03API + data model
- 04Architecture बनाएँ
- 05Deep dive
- 06Trade-off निर्णय
01
Requirements जो design तय करते हैं
सिर्फ requirements मत बताइए — पूछिए। हर card एक design constraint को उस clarification सवाल से जोड़ता है जो आप architecture बनाने से पहले बोल सकते हैं.
Functional requirements
02क्या sync अपने-आप होता है, और offline edits का क्या होता है?
Files सभी devices पर अपने-आप sync होती हैं। Offline किए गए edits जब device दोबारा connect होता है तब वापस merge हो जाते हैं। Server copy ही source of truth है।
03Sharing का मतलब क्या है — एक copy, या वही file?
Sharing उसी file तक access देती है, एक copy नहीं। पाने वाले उसे अपने view में देखते हैं। कोई भी update हर उस व्यक्ति तक पहुँचता है जिसके पास access है।
04क्या folders, moves, और renames file operations हैं?
नहीं। Folders बस metadata हैं। Move और rename सिर्फ़ metadata बदलते हैं और store किए blocks को कभी नहीं छूते, इसलिए वे किसी भी file size पर तुरंत रहते हैं।
05क्या sharing permissions रखता है — view-only बनाम edit?
हाँ। हर share एक role (viewer/editor) रखती है, और metadata service उसे enforce करता है। Presigned URLs सिर्फ़ उसी role तक सीमित होते हैं जिसने माँगा।
06क्या deletes sync होते हैं, और क्या user एक deleted file recover कर सकता है?
Deletes किसी भी दूसरे edit की तरह sync होती हैं, tombstones के ज़रिये। Blocks reclaim होने से पहले एक trash window में बैठते हैं। एक sync हो चुकी गलती को undo करने का रास्ता चाहिए।
Scope से बाहरIn-place collaborative editing (वह collaborative document-editing वाला सवाल है) · बिना download के preview और rendering · Version history UI (data model latest_version रखता है, पर history browse करना बाहर है)
Non-functional requirements
01जब network partition होता है, तब क्या काम करते रहना चाहिए?
Consistency के ऊपर availability: कुछ seconds के लिए एक stale file list ठीक है; एक upload को fail करना नहीं।
02जब एक 50 GB upload 49 GB पर मर जाता है तब क्या होता है?
यह last verified chunk से resume होता है — कभी restart नहीं। Chunk status server-side track होता है, इसलिए कोई भी device upload जारी रख सकता है।
03हमें कैसे पता चलता है कि एक file transit में corrupt नहीं हुई?
हर chunk और पूरी file SHA-256 fingerprints रखते हैं। एक chunk को uploaded तभी मार्क किया जाता है जब storage layer bytes की पुष्टि कर दे।
04दो users एक ही 2 GB video upload करते हैं — क्या हम इसे दो बार store करते हैं?
नहीं: एक जैसे fingerprints का मतलब एक जैसा content — metadata दोनों users को एक ही stored blocks की ओर इशारा करता है।
05Cross-device sync कितनी fresh होनी चाहिए?
Seconds: online devices को change notifications push होती हैं, safety net के तौर पर periodic polling के साथ।
पूछते रहिए — interview एक बातचीत है
असली interview एक साफ list से कहीं गहरा probe करते हैं. ये scope सवाल उन्हें अलग करते हैं जो problem को कुरेदते हैं बनाम जो रटते हैं.
- Max file size क्या है — megabytes या दसियों gigabytes?
- क्या collaborative in-place editing scope में है, या सिर्फ़ files-as-blobs?
- जब दो devices एक ही file offline edit करते हैं, तो user को अंत में क्या दिखना चाहिए?
- क्या हमें version history चाहिए, या बस latest version?
- क्या अलग-अलग users द्वारा upload किया गया एक जैसा content एक बार store होना चाहिए?
02
वे numbers जो architecture निर्णय मजबूर करते हैं
हर estimate को एक दबाव मानिए जो किसी component को justify करता है: cache, queue, partition, replica, worker pool, या fallback path.
Chunks per big file
50 GB file ÷ 5 MB chunks50,000 MB ÷ 5 MB = 10,000 chunks
यानी दस हज़ार uploads जो parallel में चलती हैं और हर एक अपने-आप resume हो सकती है। इसीलिए एक विशाल POST कभी काम नहीं कर सकता।
Resume cost after failure
Upload 98% पर मर जाता हैretry = बचे हुए ~200 chunks, 10,000 नहीं
Chunk-status tracking एक विनाशकारी restart को 2% top-up में बदल देता है।
Dedup win
एक ही file N users द्वारा upload की गई, fingerprint-matchedstorage cost = 1 copy + N metadata rows
Content-addressed storage दूसरे और उसके बाद के हर upload को लगभग मुफ़्त बना देता है।
Edit one byte
Fixed-size chunking बनाम content-defined chunking (CDC)fixed: 1-byte insert हर boundary shift कर देता है → लगभग सारे chunks re-upload · CDC: सिर्फ़ छुए गए chunks
CDC (rolling hash) ही वह है जो edited files के लिए delta sync को सस्ता बनाता है।
Presigned URL window
URLs ~5 minutes valid, एक chunk तक scopedleak window = minutes · blast radius = एक chunk
Short-lived, narrow-scope URLs ही client-direct upload की security story हैं।
निर्णय उदाहरण
Numbers
एक 50 GB file दस हज़ार 5 MB chunks है। उस size पर दिलचस्प problems storage नहीं हैं — वे हैं resume, dedup, और जब दो devices एक ही file edit करते हैं तब क्या होता है।
मेरी पसंद
Clients files को locally chunk और fingerprint करते हैं, फिर short-lived presigned URLs से chunks को parallel में सीधे blob storage पर upload करते हैं। API सिर्फ़ metadata संभालता है, और हर chunk का ETag verify करने के बाद ही उसे done मार्क करता है। Sync एक notification push से चलती है, फिर हर device एक changes-since cursor के विरुद्ध reconcile करता है। Conflicts के लिए, main copy के लिए last write wins। हारने वाला edit उसके बगल में एक conflict copy के रूप में रखा जाता है, ताकि user कुछ न खोए और ख़ुद उसे सुलझाए।
बचें
जो मैं नहीं करूँगा: file bytes को अपने API servers से route करना। वे शून्य फ़ायदे के लिए एक bandwidth bottleneck और एक attack surface बन जाते हैं। और मैं conflict में हारने वाले edit को चुपचाप नहीं गिराऊँगा। Pure last-write-wins एक file LIST के लिए ठीक है। पर file CONTENT के लिए, किसी की दोपहर भर की मेहनत को चुपचाप फेंक देना यही है जिससे आप customers खोते हैं।
कब बदलें
अगर in-place collaborative editing scope में आ जाए, तो blob-level sync गलत tool है। वह document structure पर operational transforms या CRDTs बन जाता है। यह एक अलग design है, और एक अलग interview सवाल।
03
Architecture path
पहले एक पूरी तस्वीर, फिर हर path को अपना अलग diagram — write path और read path अलग traffic ढोते हैं और अलग components justify करते हैं.
पूरी तस्वीर
Overview — हर component
File bytes सीधे client → blob storage बहते हैं (presigned URLs)। सिर्फ़ metadata API से गुज़रता है। Notification service दूसरे devices को changes cursor pull करने को कहता है।
Path 1
Upload path — chunk, fingerprint, direct to blob
पहले dedup check — एक known fingerprint बिना एक byte upload किए complete हो जाता है। Chunks parallel में upload होते हैं; file तभी complete में बदलती है जब हर chunk का ETag verify हो जाता है।
Path 2
Sync path — notify, then reconcile
Push दरवाज़े की घंटी है, changes cursor सच्चाई है: एक छूटी हुई notification भी अगले poll पर ख़ुद ठीक हो जाती है।
04
API और data model
optimize करने से पहले contract को inspectable बनाइए: endpoints, entities, ownership, retries, और state.
POST/files/presigned-url
req{ name, size, fingerprint, chunk_fingerprints[] }
res200 { file_id, presigned_urls[] } · 200 { deduplicated: true } जब fingerprint पहले से मौजूद हो
Client इन URLs से chunks सीधे blob storage में upload करता है — file bytes कभी API servers से नहीं गुज़रते।
PATCH/files/{file_id}/chunks
req{ chunk_id, etag }
res200 chunk status
Trust but verify: server client की progress report स्वीकार करता है, फिर chunk को uploaded गिनने से पहले blob storage के विरुद्ध ETag की पुष्टि करता है।
GET/files/{file_id}/presigned-url
res200 { url } (CDN-signed, short expiry)
Downloads CDN edge से आते हैं; short-lived signed URLs share links को permanent public URLs बनने से रोकते हैं।
GET/files/changes?since={cursor}
res200 [{ file_id, change, version }]
Sync की रीढ़: push सूचित करता है 'कुछ बदला'; यह endpoint ही वह सच्चाई है जिसके विरुद्ध एक device reconcile करता है।
Core entities
FileMetadatafile_id (PK) · name · size · fingerprint (SHA-256) · latest_version · status · chunks[] {id, fingerprint, status}
file_id (identity) जानबूझकर fingerprint (content) से अलग है — एक rename न content बदलता है, न stored blocks।
SharedFilesuser_id (partition key) · file_id (sort key)
प्रति user प्रति shared file एक row: 'यह user क्या देख सकता है' एक single-partition query है।
Devicedevice_id (PK) · user_id · last_synced_at
Sync state प्रति device है — हर device अपने खुद के cursor के बाद के changes pull करता है।
05
Deep dive दिशाएँ
interview के आखिरी एक-तिहाई के लिए एक lane चुनें. हर lane आपको topic, वह interviewer सवाल जिसका जवाब देना है, और बचने वाला failure mode देती है.
50 GB upload
Ask
Upload को end to end चलाएँ: chunking, parallelism, server क्या track करता है, और 98% पर मरने पर क्या होता है।
Answer
फ़ाइल को chunks में बाँटें, समानांतर upload करें, per-chunk स्थिति server-side track हो; 98% पर मौत आख़िरी verified chunk से resume होती है — किसी भी device पर।
बचें
एक multipart POST और retry-from-zero — इस size पर, resume ही feature है।
एक ही file, दो uploaders
Ask
दो users एक जैसी 2 GB video upload करते हैं। असल में क्या store होता है, और system को कैसे पता चलता है?
Answer
दोनों uploads का SHA-256 एक ही निकलता है, blocks एक बार store होते हैं और दोनों की metadata उन्हीं की ओर इशारा करती है; दूसरा upload बस एक metadata write है।
बचें
filename या size से deduping — सिर्फ़ content fingerprints (SHA-256) identity तय करते हैं।
दो devices offline edit करते हैं
Ask
Laptop और phone दोनों ने एक ही file offline edit की। दोनों online आते हैं। user के पास अंत में क्या रहता है?
Answer
पहले sync होने वाला साफ़ जीतता है; दूसरे device का संस्करण conflict copy के रूप में फ़ाइल के पास रहता है — उपयोगकर्ता तय करता है, सिस्टम कोई edit चुपचाप नहीं फेंकता।
बचें
चुपचाप सिर्फ़ last write रखना — हारने वाला edit एक conflict copy के रूप में बचना चाहिए।
Bytes असल में कहाँ से बहते हैं
Ask
अगर file bytes API servers से बहें तो क्या टूटता है, और presigned URLs असल में क्या protect करते हैं?
Answer
Bytes client → blob storage सीधे जाते हैं, short-lived chunk-scoped presigned URLs से; API सिर्फ़ URL जारी करता और metadata लिखता है, इसलिए फ़ाइल traffic उसे कभी नहीं दबा सकता।
बचें
Long-lived या file-wide presigned URLs — minutes की validity, एक chunk का scope।
बड़ी फ़ाइल में छोटा बदलाव
Ask
उपयोगकर्ता 50 GB फ़ाइल के बीच के कुछ bytes बदलता है। क्या हम पूरी फ़ाइल दोबारा upload करें — सिर्फ़ बदला हिस्सा कैसे sync करें?
Answer
Content-defined chunking: boundaries bytes से ही तय होती हैं, तो छोटा edit सिर्फ़ छुई हुई chunks बदलता है और sync बस वही दोबारा भेजता है।
बचें
संपादित फ़ाइलों के लिए fixed-size chunking — एक byte डालते ही आगे की हर chunk boundary खिसक जाती है, लगभग हर chunk नया दिखकर दोबारा upload होता है।
अभ्यास के लिए तैयार?
फाइल सिंक सिस्टम को ज़ोर से समझाइए और अपनी व्याख्या पर AI scoring पाइए.