স্কেলে ফাইল আপলোড: যাচাই, স্টোরেজ ও অ্যাক্সেস

কোন কারণে স্কেলে ইউজার ফাইল আপলোড কঠিন হয়ে যায়

কয়েকজন টেস্ট ইউজারের সঙ্গে আপলোডগুলো সাময়িকভাবে সহজ লাগে। কিন্তু যখন প্রকৃত মানুষ প্রকৃত ফাইল পাঠাতে শুরু করে—বড় ফটো, স্ক্যান করা PDF, বা ভুল এক্সটেনশনের রহস্যময় ডকুমেন্ট—তখন আপলোড একটি ফর্মের বাটন হয়ে থাকে না, বরং এটি একটি সিকিউরিটি ও অপারেশনস সমস্যা হয়ে ওঠে।

প্রথম ফাটলগুলো সাধারণত তিনটি জায়গায় দেখা দেয়: সিকিউরিটি, খরচ, এবং গোপনীয়তা। আক্রমণকারী-ম্যালওয়্যার আপলোড করার চেষ্টা করে, ব্যবহারকারী এমন ফাইল আপলোড করে যা আপনার অ্যাপ খুলতে পারে না, এবং টিমগুলো ভুলে সংবেদনশীল ডকুমেন্ট পাবলিক URL-এ এক্সপোজ করে দিতে পারে। স্টোরেজ বিল বাড়ে, এবং ব্যান্ডউইথ বাড়ে যখন একই ফাইল বারবার ডাউনলোড হয়।

ইমেজ ও PDF আলাদা ধরনের সমস্যা তৈরি করে। ইমেজগুলো বড় হতে পারে, অনেক ফরম্যাটে আসে, এবং প্রায়ই লুকানো মেটাডেটা (যেমন লোকেশান) থাকে। অ্যাপ দ্রুত রাখতে থাম্বনেইল ও রিসাইজিং দরকার। PDF প্রিভিউ নিরাপদভাবে দেখানো কঠিন, এমবেডেড কনটেন্ট থাকতে পারে, এবং প্রায়ই সংবেদনশীল রেকর্ড (ইনভয়েস, আইডি, কনট্রাক্ট) থাকে যা বিস্তৃতভাবে অ্যাক্সেসযোগ্য হওয়া উচিত নয়।

স্কেলে, সাধারণত অনেক ব্যবহারকারী একই সময়ে আপলোড করে, ফাইল বড় এবং মোট স্টোরেজ বেশি, ডাউনলোড ও রিট্রাই বেশি, এবং আরও নিয়ম থাকে: আলাদা টিম, রোল এবং রিটেনশন চাহিদা।

লক্ষ্য কেবল কাজ করা আপলোড নয়। লক্ষ্য হলো নিরাপদ আপলোড যা কয়েক মাস পরে পরিচালনা করা সহজ থাকে: স্পষ্ট নিয়ম, প্রত্যাশাযোগ্য স্টোরেজ পথ, অডিট-ফ্রেন্ডলি মেটাডেটা, এবং এমন অ্যাক্সেস কন্ট্রোল যা আপনার ব্যবসা কীভাবে ফাইল শেয়ার করে তার সাথে মেলে।

আপনার ফাইল টাইপ এবং কে অ্যাক্সেস করবে তা ম্যাপ করুন

স্টোরেজ বা সিকিউরিটি টিউন করার আগে পরিষ্কার করুন মানুষ কী আপলোড করবে এবং কে দেখতে পারবে। স্কেলে বেশিরভাগ আপলোড সমস্যা আসলে স্টোরেজ সমস্যা নয়—ওগুলো হলো অ্যাক্সেস, রিটেনশন, ও ঝুঁকির প্রত্যাশার মিল না হওয়া।

আসল ফাইল ক্যাটাগরি তালিকাভুক্ত করে শুরু করুন, কেবল "ডকুমেন্ট" বা "ইমেজ" না বলে। একটি অ্যাভাটার কনট্রাক্ট PDF থেকে ভিন্নভাবে আচরণ করে, এবং একটি সাপোর্ট স্ক্রিনশট মাসিক রিপোর্ট থেকে আলাদা।

একটি ব্যবহারিক উপায় হলো প্রতিটি ক্যাটাগরিকে একটি অ্যাক্সেস প্যাটার্নের সাথে জুড়া:

• অ্যাভাটার ও পাবলিক প্রোফাইল ইমেজ সাধারণত অনেকে পড়তে পারে, এবং শুধুমাত্র মালিক এডিট করতে পারে।
• রিসিট ও ইনভয়েস ডিফল্টভাবে প্রাইভেট, কেবল ফাইন্যান্স রোল বা অ্যাকাউন্ট মালিকের সাথে শেয়ার করা হয়।
• কনট্রাক্ট ও কমপ্লায়েন্স ফাইল অত্যন্ত সীমাবদ্ধ এবং প্রায়ই অডিট ট্রেইল ও কঠোর রিটেনশন দরকার।
• রিপোর্ট ও এক্সপোর্ট একটি টিমে শেয়ার করা যেতে পারে কিন্তু সঠিক ওয়ার্কস্পেস বা কাস্টমারের স্কোপে সীমাবদ্ধ হওয়া উচিত।
• টিকিট অ্যাটাচমেন্ট সাধারণত টিকিট অংশগ্রহণকারীদের জন্য প্রাইভেট এবং কখনও কখনও সময়-সীমাবদ্ধ।

তারপর দ্রুত একটি ঝুঁকি স্ন্যাপশট নিন। আপলোডে ম্যালওয়্যার লুকাতে পারে, সংবেদনশীল ডেটা (আইডি, ব্যাংক তথ্য, মেডিকেল বিবরণ) ফাঁস করতে পারে, বা ভাঙ্গা অনুমতি যেখানে একটি অনুমানযোগ্য URL-এ অ্যাক্সেস মেলে তা প্রকাশ করতে পারে। এই কারণেই স্কেলে ফাইল আপলোডগুলো বাইটের চাইতে বেশি ফাইল অ্যাক্সেস কন্ট্রোল সম্পর্কে।

পর্ফরম্যান্সও গুরুত্বপূর্ণ। বড় PDF, উচ্চ-রেজ ইমেজ, এবং ত্রুটিপূর্ণ মোবাইল নেটওয়ার্ক আংশিক আপলোড ও রিট্রাই সৃষ্টি করে। কোন আপলোডগুলো নির্ভরযোগ্যভাবে সফল হতে হবে (ইনভয়েস, আইডি) এবং কোনগুলো ঐচ্ছিক (প্রোফাইল ব্যানার) তা আগে থেকে ঠিক করুন।

প্রতিটি ফাইল টাইপের জন্য কয়েকটি প্রশ্ন আগে থেকেই উত্তর দিন যাতে পরে পুনর্লিখতে না হয়:

• কে আপলোড, দেখতে, রিপ্লেস এবং ডিলিট করতে পারবে?
• এটি প্রাইভেট, গ্রুপভিত্তিক শেয়ার বা পাবলিক?
• কি অ্যাক্সেসের মেয়াদ শেষ হবে বা তা তাৎক্ষণিকভাবে প্রত্যাহারযোগ্য হবে?
• যদি আপলোড বাধাগ্রস্ত হয়ে পুনরায় চেষ্টা করা হয় তাহলে কি হবে?
• কতক্ষণ এটি রাখবেন, এবং কে এটি এক্সপোর্ট করতে পারবে?

যদি আপনি AppMaster-এর মতো টুল দিয়ে নির্মাণ করেন, এগুলোকে প্রথমে প্রোডাক্ট নিয়ম হিসেবে বিবেচনা করুন, তারপর আপনার ডেটা মডেল ও এন্ডপয়েন্টগুলোতে বাস্তবায়ন করুন যাতে ওয়েব ও মোবাইল জুড়ে অনুমতিগুলো কনসিস্টেন্ট থাকে।

সমস্যা দ্রুত আটকাতে ফাইল আপলোড ভ্যালিডেশন রুল

স্কেলে ফাইল আপলোডগুলোকে নিরাপদ ও পূর্বানুমেয় রাখতে চাইলে ভ্যালিডেশন আপনার প্রথম সারির প্রতিরক্ষা। ভালো নিয়ম ম্যালফাংশনিং ফাইলগুলো স্টোরেজে যাওয়ার আগে থামায়, এবং ব্যবহারকারীরা স্পষ্ট প্রতিক্রিয়া পেলে সাপোর্ট টিকিটও কমে।

বর্তমানে allowlist দিয়ে শুরু করুন, blocklist দিয়ে নয়। ফাইলনেম এক্সটেনশন চেক করুন এবং একই সাথে আপলোডকৃত কনটেন্ট থেকে সনাক্ত করা MIME টাইপ নিশ্চিত করুন। কেবল এক্সটেনশনে ভর করা সহজেই উপেক্ষা করা যায়; কেবল MIME-এ ভর করাও ডিভাইসভেদে অনিশ্চিত হতে পারে।

সাইজ লিমিটগুলি ফাইল টাইপ ও আপনার প্রোডাক্ট নিয়মের সঙ্গে মানানসই হওয়া উচিত। ইমেজ 5–10MB ঠিক থাকতে পারে, যেখানে PDF-র জন্য বেশি ক্যাপ প্রয়োজন হতে পারে। ভিডিও আলাদা প্রব্লেম এবং সাধারণত আলাদা পাইপলাইন লাগে। পেইড টিয়ার থাকলে সীমা প্ল্যানে বেঁধে দিন যাতে ব্যবহারকারীকে বলা যায় “আপনার প্ল্যান 10MB পর্যন্ত PDF অনুমোদন করে”—বেজায় অস্পষ্ট এরর দেখানোর বদলে।

কিছু ফাইলের আরো গভীর চেক দরকার। ইমেজের জন্য প্রস্থ ও উচ্চতা (কখনও কখনও অ্যাসপেক্ট রেশিও) যাচাই করুন যাতে বড় আকারের আপলোড পেজ ধীর না করে। PDF-এর ক্ষেত্রে যদি আপনার ইউজ কেস ছোট পেজ কাউন্ট আশা করে, তাহলে পেজ কাউন্টও গুনে দেখা উচিত।

আপলোডে ফাইল রিনেম করুন। ব্যবহারকারীর ফাইলনেমে প্রায়ই স্পেস, ইমোজি বা একাধিক একই নাম থাকে যেমন scan.pdf। সেফ এক্সটেনশনসহ জেনারেটেড ID ব্যবহার করুন, এবং প্রদর্শনের জন্য আসল নামটি মেটাডেটাতে রাখুন।

অনেক অ্যাপে কাজ করা একটি ভ্যালিডেশন বেসলাইন হতে পারে:

• Allowlist টাইপ (এক্সটেনশন + MIME), বাকি সবকিছু প্রত্যাখ্যান করুন।
• টাইপ অনুযায়ী ম্যাক্স সাইজ সেট করুন (প্রয়োজনে প্ল্যানভিত্তিক)।
• ইমেজ ডাইমেনশন যাচাই করুন এবং অতিরিক্ত বড় সাইজ প্রত্যাখ্যান করুন।
• PDF পেজ কাউন্ট যাচাই করুন যেখানে প্রয়োজন।
• সেফ, ইউনিক ফাইলনেমে রিনেম করুন এবং আসল নাম মেটাডেটায় রাখুন।

ভ্যালিডেশন ব্যর্থ হলে ব্যবহারকারীর জন্য একটি স্পষ্ট বার্তা দেখান, যেমন “PDF গুলো 20MB এবং 50 পেজের নিচে থাকতে হবে।” একই সময়ে অ্যাডমিনদের জন্য টেকনিক্যাল ডিটেইল লগ করুন (ডিটেক্টেড MIME, সাইজ, ইউজার আইডি, এবং ব্যর্থতার কারণ)। AppMaster-এ এই চেকগুলো আপনার Business Process-এ রাখতে পারেন যাতে প্রতিটি আপলোড পাথ একই নিয়ম অনুসরণ করে।

আপলোড এবং ফাইল মেটাডেটার ডেটা মডেল

একটি ভালো ডেটা মডেল আপলোডগুলোকে বোরিং করে দেয়—এটাই চাই। লক্ষ্য হলো কে ফাইলের মালিক, এটি কী উদ্দেশ্যে, এবং এটি ব্যবহার করা নিরাপদ কি না তা ট্র্যাক করা, কোনো এক স্টোরেজ ভেন্ডরে আপনার অ্যাপকে আটাকিয়ে না রেখে।

একটি নির্ভরযোগ্য প্যাটার্ন হলো দুই-ধাপ প্রবাহ। প্রথমে ডাটাবেসে একটি আপলোড রেকর্ড তৈরি করুন এবং একটি upload ID রিটার্ন করুন। দ্বিতীয়ত, সেই ID ব্যবহার করে বাইনারি স্টোরেজে আপলোড করুন। এতে কোন রহস্যময় ফাইল বালতিতে থেমে থাকবে না, এবং আপলোডের আগে অনুমতি প্রয়োগ করা সম্ভব হয়।

একটি সাধারণ uploads টেবিল (বা কালেকশন) প্রায়ই যথেষ্ট। AppMaster-এ এটি Data Designer-এ PostgreSQL মডেলে সহজেই ম্যাপ হয় এবং ওয়েব ও মোবাইল অ্যাপ জুড়ে ব্যবহার করা যায়।

পরে সাপোর্ট ও অডিটের জন্য যা লাগবে তা সংরক্ষণ করুন:

• মালিক রেফারেন্স (user_id) এবং স্কোপ (org_id বা team_id)
• উদ্দেশ্য (avatar, invoice_pdf, ticket_attachment)
• আসল ফাইলনেম, ডিটেক্টেড MIME টাইপ, এবং size_bytes
• স্টোরেজ পয়েন্টার (bucket/container, object_key) প্লাস checksum (ঐচ্ছিক)
• টাইমস্ট্যাম্প (created_at, uploaded_at) এবং আপলোডারের IP/ডিভাইস (ঐচ্ছিক)

স্টেট মডেল ছোট রাখুন যাতে পড়তে সহজ থাকে। চারটি স্টেট বেশিরভাগ প্রোডাক্টের জন্য কভার করে:

• pending: রেকর্ড আছে, আপলোড সম্পন্ন হয়নি
• uploaded: বাইটগুলি স্টোরড হয়েছে
• verified: চেক পাস করেছে এবং ব্যবহারের জন্য প্রস্তুত
• blocked: চেক ব্যর্থ হয়েছে বা নীতির কারণে আটকানো হয়েছে

প্রথম দিন থেকেই ক্লিনআপ প্ল্যান করুন। ব্যবহারকারীরা ট্যাব বন্ধ করলে বা কানেকশন হারালে পরিত্যক্ত pending আপলোড হয়। একটি ডেইলি জব মেয়াদ উত্তীর্ণ pending রো গুলোর স্টোরেজ অবজেক্ট মুছে দিতে পারে, রিপোর্টিং-এর জন্য রো গুলোকে canceled হিসেবে মার্ক করতে পারে, পুরোনো blocked আইটেম নির্দিষ্ট রিটেনশন উইন্ডোর পর মুছে দিতে পারে, এবং verified ফাইলগুলো ব্যবসায়িক নিয়ম অনুযায়ী রাখা হবে।

এই মডেল আপনাকে ট্রেসেবিলিটি ও কন্ট্রোল দেয় জটিলতা বাড়ানো ছাড়া।

স্টোরেজ সংগঠন যাতে সময়ের সঙ্গে পরিপাটি থাকে

যখন স্কেলে ফাইল আপলোড জমতে শুরু করে, সবচেয়ে বড় ঝুঁকি স্টোরেজ খরচ নয়—এটি ঝামেলা। যদি আপনার টিম বুঝতে না পারে একটি ফাইল কী, কার এটা, এবং এটি কি এখনও প্রাসঙ্গিক, তাহলে বাগ পাঠাবেন এবং ডেটা ফাঁস হবে।

একটি প্রত্যাশাযোগ্য ফোল্ডার স্ট্র্যাটেজি বাছুন এবং তাতে স্থির থাকুন। অনেক টিম টেন্যান্ট (কোম্পানি) অনুযায়ী partition করে, তারপর purpose, তারপর তারিখ। অন্যরা টেন্যান্ট, ইউজার, পারপাস করে। সঠিক পছন্দের চেয়ে ধারাবাহিকতা বেশি গুরুত্বপূর্ণ। তারিখ ডিরেক্টরি বড় হওয়া থেকে রোধ করে এবং ক্লিনআপ জব সহজ করে।

পথ বা ফাইলনেমে ব্যক্তিগত ডেটা রাখা এড়ান—ইমেইল, পুরো নাম, ইনভয়েস নম্বর বা ফোন নম্বর এমবেড করবেন না। র‍্যান্ডম আইডি ব্যবহার করুন। যদি আপনাকে মানবিক অর্থে সার্চ করতে হয়, সেটি ডাটাবেস মেটাডেটায় রাখুন, অবজেক্ট কী-এ না।

অরিজিনাল এবং ডেরিভেটিভ আলাদা রাখুন যাতে নিয়ম স্পষ্ট থাকে। অরিজিনাল আপলোড একবার স্টোর করুন, এবং থাম্বনেইল বা প্রিভিউ আলাদা প্রিফিক্সে রাখুন। এতে বিভিন্ন রিটেনশন পলিসি ও পারমিশন প্রয়োগ করা সহজ হয় (একটি প্রিভিউ অনেক জায়গায় প্রদর্শনযোগ্য হতে পারে যেখানে অরিজিনাল সীমাবদ্ধ)।

একটি সাধারণ, স্থায়ী নামকরণ পদ্ধতি:

• টেন্যান্ট ID (বা ওয়ার্কস্পেস ID) দ্বারা পার্টিশন করুন
• একটি purpose প্রিফিক্স যোগ করুন (avatars, invoices, attachments)
• একটি টাইম বকেট যোগ করুন (YYYY/MM)
• filename হিসেবে একটি অপ্যাক ফাইল ID ব্যবহার করুন
• ডেরিভেটিভগুলো পৃথক প্রিফিক্স (previews, thumbnails) এ রাখুন

ভার্সন কীভাবে হ্যান্ডল করবেন তা সিদ্ধান্ত নিন। যদি ইউজার ফাইল রিপ্লেস করতে পারেন, তবে একই অবজেক্ট কী overwrite করুন (সহজ, ইতিহাস নেই) অথবা একটি নতুন ভার্সন তৈরি করে পুরনোটা inactive হিসেবে মার্ক করুন (অধিক অডিট-ফ্রেন্ডলি)। কমপ্লায়েন্স ডকুমেন্টের জন্য অনেক টিম ইতিহাস রেখেছে এবং প্রোফাইল ছবি overwrite করে।

আপনার নামকরণ নিয়ম লিখে রাখুন। AppMaster-এ এটাকে একটি শেয়ার্ড কনভেনশন হিসেবে রাখুন: প্রজেক্ট ডকস-এ লিখে রাখুন যাতে ব্যাকএন্ড লজিক, UI বিল্ডার এবং ভবিষ্যৎ ইন্টিগ্রেশন একই পথ জেনারেট করে।

পারমিশন ও অ্যাক্সেস কন্ট্রোল প্যাটার্ন

স্কেলে ফাইল আপলোডের ক্ষেত্রে পারমিশন থেকে ছোট শর্টকাটগুলো বড় ঘটনায় পরিণত হয়। ডিফল্টভাবে deny করে শুরু করুন: প্রতিটি আপলোড করা ফাইল প্রাইভেট যতক্ষণ না একটি নিয়ম স্পষ্টভাবে অ্যাক্সেস দেয়।

দুইটি প্রশ্ন আলাদা করে রাখা কাজে লাগে: কে রেকর্ডটি পড়তে পারে, এবং কে বাইটস ফেচ করতে পারে। এগুলো এক নয়। অনেক অ্যাপ কাউকে মেটাডেটা (ফাইল নাম, সাইজ, আপলোড তারিখ) দেখতে দেয় কিন্তু ডাউনলোড করতে দেয় না।

সাধারণ অ্যাক্সেস প্যাটার্ন

একটি ফাইল টাইপ প্রতি একটি প্রাথমিক প্যাটার্ন বাছুন, তারপর ব্যতিক্রমগুলো সাবধানে যোগ করুন:

• Owner-only: কেবল আপলোডার (এবং সার্ভিস অ্যাকাউন্ট) ডাউনলোড করতে পারে।
• Team-based: ওয়ার্কস্পেস/প্রজেক্ট সদস্যরা ডাউনলোড করতে পারে।
• Role-based: Finance বা HR মতো রোলগুলো দলভেদে ডাউনলোড করতে পারে।
• Share-by-link: একটি বিশেষ টোকেন ডাউনলোড অনুমতি দেয়, সাধারণত মেয়াদসীমা ও স্কোপসহ।

এজ কেসগুলো স্পষ্ট নিয়ম চাই, এককালীন ফিক্স নয়। অ্যাডমিন কিভাবে কাজ করবে (গ্লোবাল অ্যাক্সেস নাকি শুধুমাত্র নির্দিষ্ট ক্যাটাগরি), সাপোর্ট কিভাবে অস্থায়ী অ্যাক্সেস পাবে (সময়-সমাপ্ত ও লগ করা হয়েছে), এবং ইউজার মোছা হলে কি হবে (রিটেনশন, মালিকপদ পুনঃনিয়োগ, না মুছে ফেলা)—এসব নির্ধারণ করুন।

মেটাডেটা এবং ডাউনলোড আলাদা ভাবুন

একটি সহজ প্যাটার্ন দুইটি চেক: (1) ইউজার আপলোড রেকর্ড পড়তে পারে কি না, (2) ইউজার ডাউনলোড রিসপন্স অনুরোধ করতে পারে কি না। দ্বিতীয় চেকটি ওই জায়গা যেখানে আপনি “প্রাইভেট যতক্ষণ অনুমতি না দেয়া” নিয়ম প্রয়োগ করবেন, এমনকি কেউ ID অনুমান করলেও।

সংবেদনশীল ডকুমেন্টের ক্ষেত্রে অ্যাক্সেস লগ করুন। অন্তত: কে ডাউনলোড করেছে (ইউজার ID ও রোল), কি ডাউনলোড করেছে (ফাইল ID ও টাইপ), কখন (টাইমস্ট্যাম্প), কেন অনুমোদিত (পলিসি ফলাফল, শেয়ার টোকেন, অ্যাডমিন ওভাররাইড), এবং কোথা থেকে (IP বা ডিভাইস, যদি উপযুক্ত)।

AppMaster-এ এসব নিয়ম প্রায়ই Business Process Editor-এ থাকে: একটি ফ্লো মেটাডেটা তালিকার জন্য, এবং একটি কঠোরতর ফ্লো ডাউনলোড রেসপন্স জেনারেট করার জন্য।

মেয়াদসীমা-যুক্ত ডাউনলোড লিংক: কম ঝুঁকি, কম ঘর্ষণ

মেয়াদসীমা-যুক্ত ডাউনলোড লিংকগুলি “যার কাছে URL আছে সে সবসময় ডাউনলোড করতে পারে” এবং “প্রতি বার ব্যবহারকারীর লগইন প্রয়োজন”—এর মাঝের ভাল সমঝোতা। এগুলো ওয়ান-অফ ডাউনলোড, ইমেইলে ডকুমেন্ট শেয়ার করা, বা কন্ট্রাক্টরের জন্য অস্থায়ী অ্যাক্সেস দেওয়ার সময় ভালো কাজ করে। স্কেলে এগুলো সাপোর্ট ইস্যুও কমায় কারণ আপনি পুরো স্টোরেজ খোলে না দিয়ে নির্দিষ্ট অ্যাক্সেস দিতে পারেন।

দুটি সাধারণ প্যাটার্ন:

• Signed URLs স্বয়ংক্রিয়ভাবে মেয়াদ শেষ করে। এরা সিম্পল এবং দ্রুত, কিন্তু যদি লিংকটি ছড়িয়ে পড়ে তাহলেই রিভোকেশন কঠিন।
• টোকেন-ভিত্তিক ডাউনলোড এন্ডপয়েন্ট বেশি কন্ট্রোল দেয়। লিংকে একটি সংক্ষিপ্ত টোকেন থাকে, আপনার অ্যাপ প্রতিটি অনুরোধে অনুমতি চেক করে, তারপর ফাইল সার্ভ করে বা রিডাইরেক্ট করে।

একটি ব্যবহারিক সেটআপ:

• শেয়ারিং লিঙ্কের জন্য সংক্ষিপ্ত মেয়াদ ব্যবহার করুন (10–60 মিনিট) এবং প্রয়োজনে রিফ্রেশ দিন।
• লম্বা মেয়াদ কেবল বিশ্বাসযোগ্য, লগইন করা সেশনগুলোর জন্য রাখুন (উদাহরণ: “কম্পিউটার-এ আবার ডাউনলোড” নতুন লিংক জেনারেট করে)।
• লিঙ্কগুলোকে টাইট স্কোপ করুন: এক ফাইল, এক ব্যবহারকারী (বা রিসিপিয়েন্ট), এক অশন (view vs download)।
• লিঙ্ক তৈরির এবং ব্যবহারের লগ রাখুন যাতে লিক ট্রেস করা যায়।

স্কোপ গুরুত্বপূর্ণ কারণ view সাধারণত ইনলাইন ডিসপ্লে বোঝায়, যেখানে download মানে কপি সেভ করা। যদি দুইটাই লাগে, আলাদা নিয়মসহ আলাদা লিংক দিন।

রিভোকেশনের জন্য পরিকল্পনা করুন। যদি একজন ব্যবহারকারী এক্সেস হারায় (রিফান্ড, রোল পরিবর্তন, কনট্রাক্ট শেষ), তখন কেবল signed URL যথেষ্ট নাও হতে পারে। টোকেন এন্ডপয়েন্ট থাকলে টোকেন অবিলম্বে অবৈধ করা যায়। সাইনড URL-এর ক্ষেত্রে সংক্ষিপ্ত মেয়াদ রাখুন এবং প্রয়োজনে সাইনিং কী রোটেট করুন (কী রোটেশন সবকিছু রিভোক করে, তাই সাবধানে ব্যবহার করুন)।

উদাহরণ: একটি কাস্টমার পোর্টালের ইনভয়েস লিংক যা একটি অ্যাকাউন্ট্যান্টকে ইমেইল করা হয় 30 মিনিটে মেয়াদ শেষ হয়, view-only অনুমতি দেয়, এবং নির্দিষ্ট ইনভয়েস ID ও কাস্টমার অ্যাকাউন্টের সঙ্গে যুক্ত। যদি গ্রাহককে অ্যাকাউন্ট থেকে সরানো হয়, টোকেনটি মেয়াদ না কাটলেও রিজেক্ট হবে যদি ইমেইল ফরওয়ার্ড করা হয়।

ধাপে ধাপে: একটি স্কেলেবল আপলোড ফ্লো

একটি নির্ভরযোগ্য আপলোড ফ্লো তিনটি বিষয় আলাদা করে: আপনি কি অনুমোদন দেবেন, বাইটগুলো কোথায় যাবে, এবং পরে কে সেগুলো ফেলতে পারবে। যখন এগুলো মিশে যায়, ছোট এজ কেসগুলো প্রোডাকশনে বড় সমস্যা হয়।

ছবির, PDF-এর এবং বেশিরভাগ ইউজার-জেনারেটেড ফাইলের জন্য একটি ব্যবহারিক ফ্লো:

1. purpose-ভিত্তিক নিয়ম সংজ্ঞায়িত করুন। প্রতিটি purpose (avatar, invoice, ID document) জন্য অনুমোদিত টাইপ, ম্যাক্স সাইজ, এবং অতিরিক্ত চেক (যেমন ম্যাক্স পেজ) সেট করুন।
2. ব্যাকএন্ডে একটি আপলোড রিকোয়েস্ট তৈরি করুন। ক্লায়েন্ট আপলোডের অনুমতি চায়। ব্যাকএন্ড একটি আপলোড টার্গেট (যেমন অবজেক্ট স্টোরেজ কী + শর্ট-লাইভ টোকেন) রিটার্ন করে এবং একটি নতুন আপলোড রো pending স্টেট দিয়ে তৈরি করে।
3. বাইনারি স্টোরেজে আপলোড করে পরে কনফার্ম করুন। ক্লায়েন্ট অবজেক্ট স্টোরেজে আপলোড করে, পরে ব্যাকএন্ডকে সম্পন্ন হওয়ার কল করে। ব্যাকএন্ড প্রত্যাশিত কী ও বেসিক প্রপার্টি চেক করে, তারপর রো uploaded হিসেবে মার্ক করে।
4. অ্যাসিঙ্ক ভেরিফিকেশন চালান। ব্যাকগ্রাউন্ডে আসল ফাইল টাইপ ভেরিফাই করুন (সেরা হলে magic bytes সহ), সাইজ নিশ্চিত করুন, নিরাপদ মেটাডেটা এক্সট্র্যাক্ট করুন (ডাইমেনশন, পেজ কাউন্ট), এবং প্রয়োজনে ম্যালওয়্যার স্ক্যানিং চালান। ব্যর্থ হলে রো blocked হিসেবে মার্ক করুন এবং ডাউনলোড বন্ধ রাখুন।
5. নীতিমতো ডাউনলোড সার্ভ করুন। ডাউনলোডে যাচাই করুন যে ইউজার ফাইলের মালিক সত্তা (user, org, ticket, order) এর সাথে অ্যাক্সেস রাখে কি না। তারপর ডাউনলোড প্রোক্স করুন বা প্রাইভেট স্টোরেজ রাখার জন্য এক্সপায়ারিং লিংক রিটার্ন করুন।

ক্লিনআপ যোগ করুন। পরিত্যক্ত pending আপলোড নির্দিষ্ট সময় পর মুছে ফেলুন, এবং অনরেফারেন্সড ফাইলগুলো মুছে দিন (যেমন—ইউজার ইমেজ আপলোড করেছে কিন্তু ফর্ম কখনো সেভ করেনি)।

AppMaster-এ এটি তৈরি করলে, আপলোডগুলোকে নিজস্ব entity হিসেবে মডেল করুন status ফিল্ড ও মালিক রেফারেন্সসহ, এবং প্রতিটি ডাউনলোড Business Process-এ একই পারমিশন চেকগুলো চালু রাখুন।

উদাহরণ: কাস্টমার পোর্টালে ইনভয়েস

কাস্টমার পোর্টালে ইউজাররা PDF ইনভয়েস আপলোড করে—শোনতে সহজ। কিন্তু হাজার হাজার কোম্পানি, একাধিক রোল, এবং একই ইনভয়েস তিনবার রিপ্লেস হওয়া পর্যন্ত এটা জটিল হয়ে যায়।

স্টোরেজ সংগঠনের জন্য কাঁচা ফাইল একটি প্রত্যাশাযোগ্য পথেই রাখুন যা মানুষ কিভাবে সার্চ করে তার সাথে মেলে। উদাহরণ: invoices/<company_id>/<yyyy-mm>/<upload_id>.pdf। কোম্পানি ও মাস ক্লিনআপ ও রিপোর্টিং সহজ করে, আর upload_id টির ফলে নাম সংঘর্ষ হয় না।

ডাটাবেসে মেটাডেটা রাখুন যা বলে ফাইলটি কী এবং কে অ্যাক্সেস করতে পারে:

• company_id এবং billing_month
• uploaded_by_user_id এবং uploaded_at
• original_filename এবং content_type
• size_bytes এবং checksum (ঐচ্ছিক)
• status (active, replaced, quarantined)

শেয়ারিং: একটি বিলিং ম্যানেজার একটি ইনভয়েস 24 ঘণ্টার জন্য বাইরের অ্যাকাউন্টান্টকে পাঠাতে চায়—গ্লোবাল পারমিশন পরিবর্তন করার বদলে ঐ নির্দিষ্ট ইনভয়েসের জন্য একটি মেয়াদসীমা-যুক্ত ডাউনলোড লিংক জেনারেট করুন, কড়া এক্সপায়ারি টাইম এবং শুধুমাত্র ডাউনলোড পারপাস সহ। অ্যাকাউন্টান্ট লিংকে ক্লিক করলে আপনার অ্যাপ টোকেন যাচাই করবে, মেয়াদ শেষ নয় কি না নিশ্চিত করবে, তারপর ফাইল সার্ভ করবে।

যদি ইউজার ভুল PDF আপলোড করে বা ফাইল রিপ্লেস করে, পুরনো অবজেক্ট ওভাররাইট করবেন না। পূর্বের রেকর্ডকে replaced মার্ক করুন, এটিকে অডিটের জন্য রাখুন, এবং ইনভয়েস এন্ট্রিকে নতুন upload_id দেখান। রিটেনশন নিয়ম মেনে পরে রিপ্লেস করা ফাইলগুলো ডিলিট করা যাবে।

যখন সাপোর্টে “ডাউনলোড হচ্ছে না” টিকিট আসে, মেটাডেটা দ্রুত নির্ণয় করতে সাহায্য করে: লিংক মেয়াদোত্তীর্ণ কি, ইনভয়েস replaced হিসেবে আছে কি না, ইউজার সঠিক কোম্পানির সদস্য কি না, বা ফাইল quarantined আছে কি না। AppMaster-এ এসব চেক Business Process-এ রাখলে প্রতিটি ডাউনলোড একই নিয়ম মেনে চলে।

সাধারণ ভুল এবং কিভাবে এড়াবেন

টিমগুলো যখন প্রথমবার স্কেলে ফাইল আপলোড হ্যান্ডেল করে, বাগগুলো সাধারণত রহস্যময় নয়। তারা কয়েকটি প্রতিশ্রুতিবদ্ধ শর্টকাট থেকে আসে যা ডেমোতে ঠিক থাকে কিন্তু পরে সমস্যা করে।

• শুধুমাত্র এক্সটেনশন বা শুধুমাত্র MIME টাইপে ভর করা। আক্রমণকারী নাম বদলে দিতে পারে, এবং ব্রাউজার মিথ্যা বলতে পারে। দুইটাই চেক করুন, এবং উচ্চ ঝুঁকির ক্ষেত্রে সার্ভারে magic bytes যাচাই করুন।
• পাবলিক স্টোরেজ ব্যবহার করে শুধু পারমিশন ভর করা। একটি পাবলিক বাচেট/কন্টেইনার প্রতিটি মিস হওয়া নিয়মকে ডেটা লিক-এ পরিণত করে। স্টোরেজ ডিফল্টভাবে প্রাইভেট রাখুন এবং অ্যাপের মাধ্যমে অ্যাক্সেস গেট করুন।
• স্টোরেজ পথ বা URL-এ ব্যবহারকারী প্রদান করা নাম রাখা। invoice_john_smith.pdf ধরণের নাম ব্যক্তিগত তথ্য ফাঁস করে এবং অনুমানকে সহজ করে। অবজেক্ট কী হিসাবে র‍্যান্ডম ID ব্যবহার করুন, ডিসপ্লে নামে আসল নাম দেখান।
• একই পথে টেন্যান্ট ফাইল মেশানো এবং শক্ত পারমিশন না রাখা। /uploads/2026/01/ এর মতো পথ কোনো অনুমতি মডেল নয়। ডাউনলোড রিটার্ন করা আগে টেন্যান্ট ও ইউজার রাইট সবসময় যাচাই করুন।
• ব্যর্থ বা পরিত্যক্ত আপলোডের ক্লিনআপ স্কিপ করা। মাল্টি-পার্ট আপলোড ও রিট্রাই জংকি ফাইল রেখে যায়। একটি ব্যাকগ্রাউন্ড জব যোগ করুন যা কখনো সম্পন্ন না হওয়া pending আপলোডগুলো সরায়।

একটি ভুল টিমগুলো ভুলে যায় তা হলো রিট্রাই ও ডুপ্লিকেটগুলোর কোন প্ল্যান না থাকা। মোবাইল নেটওয়ার্ক ড্রপ করে। ইউজার দুইবার ট্যাপ করে। আপনার সিস্টেমকে “একই ফাইল আবার আপলোড” হওয়া স্বাভাবিক হিসেবে নিতে হবে।

একটি ব্যবহারিক পদ্ধতি হলো প্রথমে একটি upload ID জেনারেট করা, তারপর চাঙ্ক বা একটি সিঙ্গল ফাইল গ্রহণ করা, এবং কনফার্ম স্টেপে ভেরিফাই করে রেকর্ড verified হিসেবে মার্ক করা। একই আপলোড পুনরাবৃত্তি হলে বিদ্যমান রেকর্ড রিটার্ন করুন যেন দ্বৈত কপি না হয়।

AppMaster-এ এটি তৈরি করলে, মূল নিয়মগুলো একটি জায়গায় রাখুন (ব্যাকএন্ড লজিক) যাতে ওয়েব ও মোবাইল একইভাবে আচরণ করে, UI বদল হলে বিধিনিষেধ বজায় থাকে।

চালু করার আগে একটি দ্রুত চেকলিস্ট

বাস্তবে আপলোড খুলে দেওয়ার আগে বেসিকগুলো একবার দেখুন। স্কেলে ফাইল আপলোডের বেশিরভাগ সমস্যা ছোট ফাঁক থেকে আসে যা অনেক ব্যবহারকারী, অনেক ফাইল, এবং বহু এজ কেসে প্রकट হয়।

• Allowlist ফাইল টাইপ এবং প্রতিটি ব্যবহারকেসের জন্য সাইজ লিমিট সেট করুন (অ্যাভাটার বনাম ইনভয়েস)। এক্সটেনশন ও আসল কনটেন্ট টাইপ—দুইটাই যাচাই করুন।
• আপলোড মেটাডেটা ডাটাবেসে সংরক্ষণ করুন: কে মালিক (user, team, account), উদ্দেশ্য, এবং স্পষ্ট স্ট্যাটাস যেমন pending, verified, বা blocked।
• স্টোরেজ ডিফল্টভাবে প্রাইভেট রাখুন, এবং প্রতিটি ডাউনলোডে অনুমতি চেক প্রয়োগ করুন (লুকানো URL-এ ভর করবেন না)।
• শেয়ারিং দরকার হলে মেয়াদসীমা-যুক্ত ডাউনলোড লিংক ব্যবহার করুন, এবং লাইফটাইম সংক্ষিপ্ত রাখুন (মিনিট বা ঘন্টা, দিন নয়)।
• পথ ও ফাইলনেমে ব্যক্তিগত ডেটা রাখা এড়ান। র‍্যান্ডম ID ব্যবহার করুন, UI-তে প্রদর্শনের জন্য বন্ধুত্বপূর্ণ নাম দেখান।

পরিত্যক্ত আপলোডগুলোর জন্য একটি পরিকল্পনা রাখুন—ইউজার আপলোড শুরু করে আর শেষ না করে যাওয়া স্বাভাবিক।

একটি সাধারণ ক্লিনআপ প্ল্যান:

• নির্দিষ্ট সময় পর verified না হওয়া orphaned ফাইল মুছে দিন।
• রিপ্লেস করা ফাইলের জন্য একটি রিটেনশন উইন্ডো রাখুন, তারপর সরিয়ে ফেলুন।
• গুরুত্বপূর্ণ ইভেন্টগুলো লগ করুন (upload, validation, download, delete) যাতে সাপোর্ট তদন্ত করতে পারে।

AppMaster-এ এটি নির্মাণ করলে, Data Designer-এর মাধ্যমে PostgreSQL-এ মেটাডেটা রাখুন, Business Process Editor-এ চেকগুলো প্রয়োগ করুন, এবং ফাইল সার্ভ করার আগে শর্ট-লাইভ ডাউনলোড টোকেন জেনারেট করুন।

পরবর্তী ধাপ: নিরাপদভাবে চালু করুন, তারপর ধীরে উন্নতি করুন

নিরাপদ রিলিজের দ্রুততম উপায় হলো একটি আপলোড পন্থা বেছে নিয়ে তাতে ধারাবাহিক থাকা। সিদ্ধান্ত নিন ফাইলগুলো প্রথমে আপনার ব্যাকএন্ড হয়ে যাবে, না কি শর্ট-লাইভ টোকেনসহ সরাসরি অবজেক্ট স্টোরেজে আপলোড হবে। তারপর প্রত্যেক ধাপ এবং কাদের দায়িত্ব তা লিখে রাখুন (ক্লায়েন্ট, ব্যাকএন্ড, স্টোরেজ)। ধ্রুবকতা কৌশল্যকে হারায় যখন আপনি ফাইল আপলোড নিয়ে কাজ করছেন।

কঠোর ডিফল্ট দিয়ে শুরু করুন। প্রয়োজনীয় ফাইল টাইপগুলোতেই সীমা দিন, সাইজ লিমিট সংরক্ষিত রাখুন, এবং যা পাবলিক নয় তা অবশ্যই অথেনটিকেশন দাবি করুন। যদি ব্যবহারকারী বড় ফাইল বা বেশি ফরম্যাট চায়, একবারে শুধু এক নিয়ম শিথিল করুন এবং প্রভাব মাপুন।

প্রাথমিক পর্যায়ে বেসিক মনিটরিং যোগ করুন যাতে সমস্যা দ্রুত দেখা যায়:

• আপলোড ব্যর্থতার হার (ডিভাইস, ব্রাউজার, ফাইল টাইপ অনুযায়ী)
• গড় ও p95 আপলোড সাইজ
• আপলোডের সময় (বিশেষত মোবাইল নেটওয়ার্কে)
• স্টোরেজ বৃদ্ধি প্রতিদিন বা প্রতি সপ্তাহে
• ডাউনলোড এরর (মেয়াদোত্তীর্ণ বা ফরবিডেন লিংকসহ)

এই আপলোড সিস্টেম যদি বড় অ্যাপের অংশ হয়, ডেটা মডেল ও পারমিশনগুলোকে আপনার ব্যবসায়িক লজিকের পাশে রাখুন। AppMaster ব্যবহারকারী প্রায়শই আপলোড রেকর্ডগুলো PostgreSQL-এ রাখে, ভ্যালিডেশন ও ফাইল অ্যাক্সেস কন্ট্রোল Business Processes-এ বাস্তবায়ন করে, এবং একই লজিক ব্যাকএন্ড, ওয়েব ও নেটিভ মোবাইল অ্যাপে পুনঃব্যবহার করে।

একটি দরকারী পরবর্তী উন্নতি হতে পারে পরিচিত ফরম্যাটগুলোর জন্য প্রিভিউ যোগ করা, সংবেদনশীল ডকুমেন্টের জন্য অডিট লগ, বা সাধারণ রিটেনশন নীতি (উদাহরণ: অস্থায়ী আপলোড 30 দিনের পরে স্বয়ংক্রিয় মুছে দেওয়া)। ছোট, ধারাবাহিক আপগ্রেড সিস্টেমকে ব্যবহার বৃদ্ধির সাথে নির্ভরযোগ্য রাখে।