यूज़र को दो गीगाबाइट तक की फाइलें अपलोड करनी हैं। आप इसे शुरू से आखिर तक कैसे डिज़ाइन करेंगे?

bytes को अपने API से होकर मत भेजिए। क्लाइंट presigned upload URL मांगे, बड़ी फाइलों के लिए multipart upload से सीधे object storage पर अपलोड करे, और फिर आपकी service को बताए, जो object की पुष्टि करके metadata दर्ज करे। content type और size की सीमाएं policy स्तर पर जांचें, फाइल के इस्तेमाल लायक होने से पहले उसे asynchronously scan करें, और downloads के लिए objects को public करने की जगह छोटी उम्र वाले signed URLs बनाएं।

पहला फैसला यह है कि फाइल कभी मेरे API से होकर नहीं जाएगी, क्योंकि दो गीगाबाइट request handler से गुज़ारने पर एक worker बंधा रहता है, bandwidth दो बार लगती है, और connection टूटते ही सब बिखर जाता है। तो क्लाइंट मेरी service से presigned upload URL मांगता है, जो एक ही key, एक ही content type और छोटी expiry तक कसकर सीमित होता है, और सीधे object storage पर अपलोड करता है। इस आकार की फाइलों के लिए मैं multipart upload लेता हूं, जिससे resumability मिलती है, क्योंकि नाकाम हुआ part ही दोबारा भेजा जाता है, पूरी फाइल नहीं। अपलोड पूरा होने पर क्लाइंट callback करता है, या इससे बेहतर, storage खुद एक event भेजता है, और मेरी service metadata लिखने से पहले जांचती है कि object मौजूद है और अपेक्षित आकार से मेल खाता है। फाइल pending स्थिति में शुरू होती है और asynchronous processing के बाद ही इस्तेमाल लायक बनती है: scanning, extension पर भरोसा करने की जगह bytes से असली content type जांचना, और जो thumbnails चाहिए वे बनाना। downloads authorization जांच के बाद जारी किए गए छोटी उम्र वाले signed URL से होते हैं, कभी किसी public bucket से नहीं, क्योंकि हैरतअंगेज़ रूप से बहुत से डेटा लीक वहीं से आते हैं।