Object storage (S3-ধাঁচ): বড় পরিসরে ফাইল রাখা
ছবি, ভিডিও ও backup থাকবে object storage-এ, database-এ নয়। এটি কীভাবে কাজ করে আর upload নিরাপদ ও সস্তা রাখার pattern জানুন।
Object storage (Amazon S3, Google Cloud Storage, Cloudflare R2, MinIO) ফাইলকে object হিসেবে bucket-এ রাখে। প্রতিটি object-এর একটি অনন্য key (যেমন photos/2026/10/a.jpg), data নিজে আর কিছু metadata থাকে। আসল folder গাছ নেই। key-র স্ল্যাশ নামেরই অংশ।
Database নয় কেন
বড় ফাইল database-কে ধীর ও দামি করে: backup বড়, query ধীর, memory চাপ। Object storage বড়, কম বদলানো blob-এর জন্য বানানো এবং প্রতি গিগাবাইটে অনেক সস্তা। ফাইল রাখুন object storage-এ, আর database-এ শুধু তার key বা URL।
মূল বৈশিষ্ট্য
- অতি উচ্চ durability। S3 Standard 99.999999999% (এগারো নাইন) durability-র জন্য ডিজাইন করা, একাধিক জায়গায় data রেখে।
- প্রায় অসীম আকার।
- Object immutable। অংশ edit না করে পুরো object বদলাতে হয়।
- API দিয়ে HTTP-তে অ্যাক্সেস, তাই সামনে CDN রাখা সহজ।
- Storage class খরচ ও গতির লেনদেন করে (hot, infrequent, archive)।
Upload pattern
Presigned URL। আপনার server অল্প সময়ের একটি signed URL বানায় আর client সরাসরি storage-এ upload করে। আপনার server ফাইল বহন করে না, তাই bandwidth ও CPU বাঁচে। আকার, content type ও মেয়াদ সীমিত করুন।
Multipart upload। বড় ফাইল ভেঙে সমান্তরালে upload করুন। ব্যর্থ অংশ আবার চেষ্টা করা যায়, গোড়া থেকে নয়।
ফাইল সার্ভ করা
Public কনটেন্টের সামনে CDN রাখুন। Private ফাইলের জন্য মেয়াদযুক্ত signed URL। ভুলে bucket public করবেন না, কারণ খোলা bucket data leak-এর ক্লাসিক উৎস।
অন্যান্য অভ্যাস
- Lifecycle rule পুরোনো object নিজে সরায় বা মোছে।
- Versioning ভুলে overwrite বা delete থেকে বাঁচায়।
- Upload প্রসেস (ছবি ছোট করা, malware স্ক্যান) queue দিয়ে async করুন।
- User-এর পাঠানো ফাইলের নাম বা ধরন বিশ্বাস করবেন না।
মূল কথা: ফাইল রাখুন object storage-এ, database-এ শুধু key, presigned URL দিয়ে upload করুন, আর bucket-এর অ্যাক্সেস কড়া করুন।
System Design সিরিজ, পর্ব ২ (building block): 5 নম্বর (মোট 14)। আগের লেখা: Elasticsearch ও full-text search: inverted index কীভাবে কাজ করে.
