File storage — object storage, presigned URL আর image pipeline

১ · Local disk কেন যথেষ্ট নয় — দুটি server আর একটি deploy

পর্ব ৩০-এ “বাজারঘর” পণ্যের ছবি নিত multer দিয়ে, magic bytes যাচাই করত, sharp দিয়ে নতুন ছবি বানিয়ে রাখত server-এর storage/products/ ফোল্ডারে। একটি server থাকা পর্যন্ত এটি ভালো চলে। এবার দোকান বড় হলো। ঈদের আগে ভিড় সামলাতে আপনি দ্বিতীয় একটি server চালু করলেন, সামনে বসালেন একটি load balancer, যা অনুরোধ পালা করে দুই server-এ পাঠায়।

রহিমা আপা ছবি তুললেন। অনুরোধটি গেল server A-তে, ছবি বসল A-এর disk-এ। এক মুহূর্ত পরে ক্রেতার browser ছবিটি চাইল, আর load balancer অনুরোধটি পাঠাল server B-তে। B-এর disk-এ এই ছবি নেই, তাই উত্তর 404. একই পাতা আবার খুললে হয়তো A-তে যাবে, ছবি দেখা যাবে। এমন “কখনো আছে, কখনো নেই” বাগ খুঁজে পাওয়া সবচেয়ে কঠিনগুলোর একটি।

দ্বিতীয় সমস্যা deploy. আধুনিক deploy প্রায়ই পুরোনো server বা container ফেলে দিয়ে নতুন একটি চালু করে। Container-এর ভেতরের লেখা ফাইল সেই container-এর সাথেই মুছে যায়, যদি না আলাদা volume থাকে। অনেক PaaS আর serverless পরিবেশে disk সাময়িক, বা আদৌ লেখা যায় না। তৃতীয় সমস্যা backup আর আকার: একটি disk ভরে গেলে বড় disk কিনে ফাইল সরাতে হয়, আর সেই disk নষ্ট হলে সব ছবি একসাথে যায়।

শেষ দুটি সারি খেয়াল করুন। Object storage database নয়, আর সাধারণ ফাইল সিস্টেমও নয়। একটি object লেখা হয় পুরোটা একসাথে, পড়া হয় পুরোটা বা একটি byte-range. ছবি, PDF, ভিডিও, backup-এর মতো “একবার লিখি, বহুবার পড়ি” ধরনের ডেটার জন্য এটি দারুণ। কিন্তু প্রতি সেকেন্ডে বদলানো log ফাইল বা database-এর ডেটা এখানে রাখা ভুল। ভেতরের নকশা, যেমন ডেটা কয়েক জায়গায় কপি রাখা আর erasure coding, System Design কোর্সের object storage পর্বে আছে; এখানে আমরা app লেখকের চোখে দেখব।

২ · Object storage-এর ভাষা — bucket, key, object, metadata

চারটি শব্দ জানলেই S3-ধাঁচের সব API পড়া যায়।

নিজের মেশিনে একটি S3-সামঞ্জস্যপূর্ণ server

শেখার জন্য cloud account লাগে না। পরিকল্পনা ছিল MinIO চালানো, কারণ বহু বছর এটিই ছিল নিজে চালানোর জনপ্রিয় S3-সামঞ্জস্যপূর্ণ server. কিন্তু লেখার সময়ে (নভেম্বর ২০২৬) তার ডাউনলোড ঠিকানা থেকে binary চাইলে উত্তর এলো 410 Gone, সাথে বার্তা: open-source MinIO Server আর Client প্রকল্প archive করা হয়েছে, আর রক্ষণাবেক্ষণ হয় না। প্রকল্পের নিজের ঘোষণা আর GitHub পাতা অনুযায়ী এটি ধাপে ধাপে ঘটেছে: ২০২৫ সালে community সংস্করণের তৈরি binary দেওয়া বন্ধ হয় আর প্রকল্পটি maintenance mode-এ যায়, তারপর ২০২৬ সালে GitHub repository archive, অর্থাৎ শুধু পড়া যায়। কোম্পানিটি তার বাণিজ্যিক পণ্য চালিয়ে যাচ্ছে বলে জানা যায়, আর কিছু community fork-ও আছে; তবে এদের ভবিষ্যৎ আমরা যাচাই করিনি। নিজে চালানো সফটওয়্যারের এই ঝুঁকিটিও শেখার বিষয়, আমরা অংশ ৯-এ ফিরব।

তাই আমরা নিলাম SeaweedFS 4.52, একটি open-source বিতরণকৃত storage, যার একটি S3 gateway আছে। GitHub release-এর Windows zip নামিয়ে SHA-256 মিলিয়ে নেওয়া হয়েছিল, release পাতার digest-এর সাথে হুবহু এক, আর প্রকল্পের দেওয়া MD5 ফাইলও মিলেছে। সব port 127.0.0.1-এ, telemetry বন্ধ। SDK হলো @aws-sdk/client-s3 3.1161.0, যা লেখার সময়ে npm-এর latest. পুরোনো aws-sdk (v2)-কে npm নিজেই বলছে end-of-support, তাই নতুন কোডে v3.

npm install @aws-sdk/client-s3@3.1161.0 @aws-sdk/s3-presigned-post@3.1161.0 \
  @aws-sdk/s3-request-presigner@3.1161.0 sharp@0.35.5 express@5.3.0 pg@8.23.1

weed server -dir=./swdata -ip=127.0.0.1 -master.telemetry=false \
  -filer -s3 -s3.port=47904 -s3.config=./s3.json

import { S3Client } from '@aws-sdk/client-s3';

export const s3 = new S3Client({
  endpoint: 'http://127.0.0.1:47904',     // নিজের store; AWS-এ এটি লাগে না
  region: 'us-east-1',
  forcePathStyle: true,                   // http://host/bucket/key আকারে
  requestChecksumCalculation: 'WHEN_REQUIRED',   // কেন, অংশ ৩-এ
  credentials: {
    accessKeyId: process.env.S3_KEY,      // .env-এ, কখনো client-এ নয়
    secretAccessKey: process.env.S3_SECRET,
  },
});

আমাদের .env-এ ছিল একেবারে নকল মান, যেমন BAZARGHAREXAMPLEKEY আর example-secret-not-real-…. Secret কোথায় রাখবেন, সেটি পর্ব ৭৮-এর বিষয়। এবার চারটি object লিখে তালিকা চাইলাম। সত্যিকারের run:

flat keys: ["incoming/x.jpg","products/a2/one.webp","products/a2/two.webp","products/d4/three.webp"]
prefix products/ delimiter / → {"CommonPrefixes":["products/a2/","products/d4/"],"Contents":[]}
head: {"ContentType":"image/webp","ContentLength":25,"ETag":"\"94e6cdeedd044e4fd51d866ec62e232d\"",
       "Metadata":{"uploaded-by":"user-17"}}
after delete: NoSuchKey 404
delete again status: 204

প্রথম লাইনে কোনো “folder” নেই, আছে চারটি লম্বা নাম, বর্ণানুক্রমে। দ্বিতীয় লাইনে আমরা Prefix: 'products/' আর Delimiter: '/' দিলাম, আর store নামগুলোকে পরের / পর্যন্ত কেটে দলে ভাগ করল: products/a2/ আর products/d4/. File explorer-এর folder দেখানোর এটাই কৌশল। এর মানে, “folder rename” বলে কোনো সস্তা কাজ নেই। products/-কে catalog/ করতে হলে প্রতিটি object কপি করে নতুন key-তে লিখে পুরোনোটি মুছতে হয়।

শেষ দুই লাইন দেখায়, মুছে ফেলা object পড়তে গেলে 404 NoSuchKey, কিন্তু একই key আবার মুছলেও 204. মোছা idempotent, যা retry-তে সুবিধা দেয়। ETag এখানে ছোট object-এর MD5-এর মতো দেখায়, কিন্তু বড় ফাইল টুকরো করে পাঠালে তা আর MD5 থাকে না; তাই ETag-কে hash ধরে নেবেন না।

৩ · Presigned URL-এর ভেতরে — সই হাতে বানানো

পর্ব ৩০-এ presigned URL ছিল মেলার সিলমারা স্লিপ: server গোপন চাবি দিয়ে সই করে, store সই আর সময় মেলায়, চাবি কখনো browser-এ যায় না। এবার সেই সিল কীভাবে তৈরি হয়, তা হাতে করে দেখি। AWS তার documentation-এ query-string সইয়ের একটি উদাহরণ দেয়: নকল চাবি AKIAIOSFODNN7EXAMPLE, একটি নির্দিষ্ট তারিখ, আর তার প্রত্যাশিত সই। নিচের কোড শুধু node:crypto দিয়ে সেই সই আবার বানায়। এখানে কোনো আসল চাবি নেই, কোনো নেটওয়ার্কও নয়।

// AWS-এর docs-এর উদাহরণ মান (নকল চাবি), হাতে SigV4 presigned GET
const { createHash, createHmac } = require('node:crypto');
const sha = (s) => createHash('sha256').update(s).digest('hex');
const hmac = (k, s) => createHmac('sha256', k).update(s).digest();

const ACCESS = 'AKIAIOSFODNN7EXAMPLE';
const SECRET = 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY';
const host = 'examplebucket.s3.amazonaws.com', key = '/test.txt';
const date = '20130524', amzDate = '20130524T000000Z', region = 'us-east-1';
const scope = `${date}/${region}/s3/aws4_request`;

const q = [['X-Amz-Algorithm', 'AWS4-HMAC-SHA256'],
  ['X-Amz-Credential', `${ACCESS}/${scope}`], ['X-Amz-Date', amzDate],
  ['X-Amz-Expires', '86400'], ['X-Amz-SignedHeaders', 'host']]
  .map(([k, v]) => `${k}=${encodeURIComponent(v)}`).join('&');

// ধাপ ১: canonical request — কী সই হচ্ছে, তার হুবহু লেখা
const canonical = ['GET', key, q, `host:${host}\n`, 'host', 'UNSIGNED-PAYLOAD'].join('\n');
// ধাপ ২: string to sign
const toSign = ['AWS4-HMAC-SHA256', amzDate, scope, sha(canonical)].join('\n');
// ধাপ ৩: চাবি থেকে চার ধাপে signing key
let k = hmac('AWS4' + SECRET, date);
for (const part of [region, 's3', 'aws4_request']) k = hmac(k, part);
// ধাপ ৪: সই
const sig = createHmac('sha256', k).update(toSign).digest('hex');

console.log('canonical hash:', sha(canonical).slice(0, 16) + '…');
console.log('signature:', sig);
const docs = 'aeeed9bbccd4d02ee5c0109b86d86835f995330da4c265957d157751f604d404';
console.log('matches AWS docs example:', sig === docs);
const c2 = canonical.replace('/test.txt', '/test.txT');       // key-এ এক অক্ষর বদল
const bad = createHmac('sha256', k).update(toSign.replace(sha(canonical), sha(c2))).digest('hex');
console.log('key test.txT → same signature?', sig === bad);
console.log('URL ends: …&X-Amz-Signature=' + sig.slice(0, 12) + '…');

চারটি ধাপ মনে রাখুন। Canonical request হলো method, path, query, সই করা header আর payload-এর একটি নির্দিষ্ট রূপ। তার SHA-256 নিয়ে বানানো হয় string to sign. গোপন চাবি থেকে তারিখ, region আর service দিয়ে পরপর HMAC করে আসে signing key, যা শুধু সেই দিন আর সেই region-এ চলে। শেষে সেই key দিয়ে string-এর HMAC, যা signature. যা কিছু canonical request-এ ঢোকে, তা-ই সুরক্ষিত; যা ঢোকে না, পথে বদলালেও store টের পায় না।

SDK-এর একটি ফাঁদ: খালি body-র checksum

শেষ কথাটির বাস্তব উদাহরণ পেলাম প্রথম run-এই। SDK দিয়ে PUT-এর presigned URL বানিয়ে browser থেকে পাঠালাম, আর store ফেরাল 400 BadDigest. URL-এর query খুলে দেখা গেল কারণ। সত্যিকারের run, SDK 3.1161.0:

default       X-Amz-Algorithm X-Amz-Content-Sha256 X-Amz-Credential X-Amz-Date X-Amz-Expires
              X-Amz-Signature X-Amz-SignedHeaders x-amz-checksum-crc32 x-amz-sdk-checksum-algorithm x-id
              signed: content-length;content-type;host   crc32: AAAAAA==
WHEN_REQUIRED X-Amz-Algorithm X-Amz-Content-Sha256 X-Amz-Credential X-Amz-Date X-Amz-Expires
              X-Amz-Signature X-Amz-SignedHeaders x-id
              signed: content-length;content-type;host   crc32: null

Default অবস্থায় SDK URL-এ একটি checksum বসিয়েছে: AAAAAA==, যা আসলে শূন্য byte-এর CRC32. URL বানানোর সময় SDK-এর কাছে ফাইল ছিল না, তাই সে খালি body-র হিসাব লিখেছে। Browser ৮,৩১,০৩৬ byte পাঠাল, store মেলাল, মিলল না। requestChecksumCalculation: 'WHEN_REQUIRED' দেওয়ার পরে এই দুটি প্যারামিটার আর এলো না, আর upload চলল। AWS-এর নিজের S3 এই প্যারামিটার কীভাবে সামলায়, তা আমরা পরীক্ষা করিনি; কিন্তু শিক্ষা একটাই: presigned URL-এর প্রতিটি query প্যারামিটার পড়ুন, আর নিজের store-এ সত্যিকারের upload চালিয়ে দেখুন।

৪ · Browser থেকে সরাসরি store-এ — presigned POST, PUT আর CORS

পুরো ব্যবস্থাটি আগে এক ছবিতে দেখে নিন। তারপর প্রতিটি তীর আলাদা করে চালাব।

POST না PUT

Browser থেকে সরাসরি পাঠানোর দুটি পথ। Presigned PUT হলো একটি URL, যেখানে ফাইলটি body হয়ে যায়। Presigned POST হলো একটি HTML form-এর অনুমতি: URL-এর সাথে কয়েকটি field, যার একটি policy. Policy-তে লেখা থাকে শর্ত, যেমন আকার কত থেকে কত। PUT-এ আকারের সীমা দেওয়ার মানসম্মত উপায় নেই; বড়জোর Content-Length সইয়ে ঢুকিয়ে একটি নির্দিষ্ট আকার বেঁধে দেওয়া যায়। তাই browser upload-এ POST policy সাধারণত বেশি কড়া। আমাদের server POST-এর policy বানায় এভাবে:

app.post('/api/uploads/presign', requireLogin, async (req, res) => {
  const { type, size } = req.body ?? {};
  if (!TYPES[type]) return res.status(415).json({ error: 'TYPE_NOT_ALLOWED' });
  if (!Number.isInteger(size) || size < 1 || size > MAX) {
    return res.status(413).json({ error: 'TOO_LARGE', max: MAX });
  }
  const id = randomUUID();
  const key = `incoming/${id}.${TYPES[type]}`;       // key আমরা ঠিক করি
  await pool.query(`insert into uploads (id, owner_id, key, declared_type, declared_size)
                    values ($1, $2, $3, $4, $5)`, [id, req.user.id, key, type, size]);
  const post = await createPresignedPost(s3, {
    Bucket: PRIVATE, Key: key, Expires: 300,
    Fields: { 'Content-Type': type },
    Conditions: [['content-length-range', 1, MAX], ['eq', '$Content-Type', type]],
  });
  res.json({ id, key, ...post });                    // { url, fields }
});

Policy আসলে Base64 করা JSON. খুলে দেখলে (সত্যিকারের run, একটি নমুনা key দিয়ে বানানো):

{ "expiration": "2026-11-02T18:24:53Z",
  "conditions": [
    ["content-length-range", 1, 5242880],
    ["eq", "$Content-Type", "image/jpeg"],
    {"Content-Type": "image/jpeg"}, {"bucket": "bazarghar-private"},
    {"X-Amz-Algorithm": "AWS4-HMAC-SHA256"},
    {"X-Amz-Credential": "BAZARGHAREXAMPLEKEY/20261102/us-east-1/s3/aws4_request"},
    {"X-Amz-Date": "20261102T181953Z"}, {"key": "incoming/3f9c1b7e.jpg"} ] }

এই পুরো লেখাটিই সই হয়। Browser কোনো শর্ত বদলালে সই আর মেলে না। এবার Edge 156-এ, Playwright দিয়ে চালানো সত্যিকারের upload. পাতাটি ছিল আমাদের app-এর http://127.0.0.1:47910 থেকে, আর ছবি একটি কৃত্রিম ৩০০০×২২৫০ JPEG, ৮,৩১,০৩৬ byte.

POST /api/uploads/presign
{"type":"image/jpeg","size":831036,"mode":"post"}

id      f945ed61-…
key     incoming/f945ed61-….jpg
status  pending   declared_size 831036

url: http://127.0.0.1:47904/bazarghar-private
fields: Content-Type, bucket, X-Amz-Algorithm,
  X-Amz-Credential, X-Amz-Date, key, Policy,
  X-Amz-Signature

POST /bazarghar-private   (multipart/form-data)
… 8 fields … file=ilish.jpg (831036 bytes)
← 204

HeadObject  → size 831036, type image/jpeg
Range 0-15  → magic ffd8ffdb
begin; status='uploaded'; insert job; commit
← 202 {"status":"uploaded"}

← 200 {"status":"uploaded","again":true}
নতুন job নেই, নতুন সারি নেই

এবার একই পাতা থেকে ইচ্ছা করে কয়েকটি মিথ্যা বলা হলো। প্রতিটি সারি Edge-এর সত্যিকারের ফল:

শেষ সারিটি সবচেয়ে জরুরি। সই প্রমাণ করে অনুমতি, ফাইলের ভেতর নয়। Store “ধরন image/jpeg” লেবেলটি মিলিয়েছে, কারণ লেবেল browser নিজেই পাঠিয়েছিল। ভেতরের byte <?ph, যা ধরা পড়েছে কেবল complete-এর magic bytes যাচাইয়ে। তাই incoming/ কখনো public নয়, আর যাচাইয়ের আগে কোনো ফাইল ব্যবহারকারীর সামনে যায় না।

Bucket-এর CORS — আর CORS কী নয়

পাতাটি চলছে 127.0.0.1:47910 origin-এ, আর store 127.0.0.1:47904-এ। Port আলাদা মানে origin আলাদা, তাই browser same-origin নীতি মেনে store-এর অনুমতি চায়। পর্ব ৫০-এ app-এর CORS দেখেছেন; এখানে নিয়মটি বসে bucket-এ:

await s3.send(new PutBucketCorsCommand({ Bucket: PRIVATE, CORSConfiguration: { CORSRules: [{
  AllowedOrigins: ['https://bazarghar.example'],   // ডেমোতে http://127.0.0.1:47910
  AllowedMethods: ['PUT', 'POST'],
  AllowedHeaders: ['content-type'],
  ExposeHeaders: ['ETag'],
  MaxAgeSeconds: 600,
}] } }));

PUT-এ content-type: image/jpeg header থাকায় browser আগে একটি preflight OPTIONS পাঠায়। curl দিয়ে দুই origin থেকে সেটি নকল করলাম, সত্যিকারের run:

== Origin http://127.0.0.1:47910
HTTP/1.1 200 OK
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Methods: PUT, POST
Access-Control-Allow-Origin: http://127.0.0.1:47910
Access-Control-Expose-Headers: ETag
Access-Control-Max-Age: 600
Vary: Origin

== Origin http://127.0.0.1:47912
HTTP/1.1 403 Forbidden
<Error><Code>AccessDenied</Code><Message>Access Denied.</Message>…

তারপর একটি অন্য origin (47912) থেকে Edge-এ দুটি বৈধ সই করা upload চালালাম, একটি PUT আর একটি POST. দুটিতেই JavaScript পেল TypeError: Failed to fetch, আর console-এ লেখা “blocked by CORS policy”. কিন্তু পরে store-এ খোঁজ নিয়ে দেখা গেল:

incoming/cors-put.txt  NotFound
incoming/cors-post.txt EXISTS 10

PUT-টি preflight-এই আটকে গিয়েছিল, তাই পাঠানোই হয়নি। কিন্তু POST একটি “simple request” (form-এর মতো multipart/form-data, বাড়তি header নেই), তাই browser preflight ছাড়াই পাঠিয়েছে। Store সই মিলিয়ে ফাইল রেখে দিয়েছে; browser শুধু উত্তরটি JavaScript-কে পড়তে দেয়নি। CORS নিরাপত্তার দেয়াল নয়, browser-এর পড়ার অনুমতি। কে লিখতে পারবে, তা ঠিক করে সই, তার মেয়াদ আর policy-র শর্ত। এজন্যই presign route-এ login, আর ছোট মেয়াদ।

৫ · Server-এ নিশ্চিত করা আর PostgreSQL-এ হিসাব

ফাইল এখন দুই জায়গায় বাস করে: byte store-এ, হিসাব database-এ। দুটি আলাদা ব্যবস্থা একসাথে পাল্টায় না, তাই ক্রম আর অবস্থা আগে থেকে ঠিক করতে হয়। “বাজারঘর”-এর uploads সারির জীবন:

app.post('/api/uploads/:id/complete', requireLogin, async (req, res) => {
  const { rows: [u] } = await pool.query(
    'select * from uploads where id = $1 and owner_id = $2', [req.params.id, req.user.id]);
  if (!u) return res.status(404).json({ error: 'NOT_FOUND' });
  if (u.status !== 'pending') return res.json({ id: u.id, status: u.status, again: true });

  let head;
  try { head = await s3.send(new HeadObjectCommand({ Bucket: PRIVATE, Key: u.key })); }
  catch (e) { return res.status(409).json({ error: 'NOT_UPLOADED_YET' }); }
  const first = await s3.send(new GetObjectCommand({ Bucket: PRIVATE, Key: u.key, Range: 'bytes=0-15' }));
  const hex = Buffer.from(await first.Body.transformToByteArray()).toString('hex');
  const ok = head.ContentLength === u.declared_size && hex.startsWith(MAGIC[u.declared_type]);

  const db = await pool.connect();
  try {
    await db.query('begin');
    await db.query(`update uploads set status = $2, completed_at = now() where id = $1`,
      [u.id, ok ? 'uploaded' : 'rejected']);
    await db.query(`insert into jobs (kind, payload) values ($1, $2)`,
      ok ? ['image.variants', { uploadId: u.id }] : ['upload.delete', { key: u.key }]);
    await db.query('commit');
  } catch (e) { await db.query('rollback'); throw e; } finally { db.release(); }
  res.status(ok ? 202 : 422).json({ id: u.id, status: ok ? 'uploaded' : 'rejected' });
});

চারটি সিদ্ধান্ত লুকিয়ে আছে এই কোডে।

• মালিকানা: owner_id = $2. অন্যের upload id জানলেও কেউ সেটি “complete” করতে পারবে না। এটি পর্ব ৪৮-এর ownership যাচাই।
• Client-কে নয়, store-কে বিশ্বাস: আকার আসে HeadObject থেকে, ধরন আসে প্রথম ১৬ byte থেকে। পুরো ফাইল নামানো হয়নি, শুধু একটি byte-range.
• সারি আর job এক transaction-এ: “uploaded” লেখা হলো অথচ job হারাল, এমন অর্ধেক অবস্থা আর সম্ভব নয়। এটি পর্ব ৪৩-এর outbox ধারণা: job-এর সারিটিই outbox, যা worker পরে পড়বে।
• Idempotent: দ্বিতীয় ডাকে একই ফল, যা পর্ব ৩৩-এর idempotency-র সরল রূপ।

Key কে বানায়: random না content-hash

incoming/-এর key random UUID, কারণ তখনো আমরা ফাইলটি দেখিনি। কিন্তু চূড়ান্ত ছবির key worker বানায় ফাইলের content hash থেকে। একই byte মানে একই নাম, বদলানো byte মানে নতুন নাম। নিচের কোড চালিয়ে দেখুন:

// Content-addressed key: ফাইলের byte থেকে নাম
const { createHash } = require('node:crypto');

function keyFor(bytes, ext) {
  const h = createHash('sha256').update(bytes).digest('hex');
  // প্রথম ২ অক্ষরে ভাগ: একই prefix-এ লাখো key জমে না
  return { hash: h, key: `products/${h.slice(0, 2)}/${h.slice(0, 32)}.${ext}` };
}

// তিনটি "ছবি": a আর c-এর byte হুবহু এক, নাম আলাদা
const files = [
  { name: 'ilish.jpg', bytes: Buffer.from('JPEG…ilish-pixels…v1') },
  { name: 'ilish-new.jpg', bytes: Buffer.from('JPEG…ilish-pixels…v2') },
  { name: 'IMG_0042.jpg', bytes: Buffer.from('JPEG…ilish-pixels…v1') },
];

const store = new Map();          // key → bytes, object store-এর মডেল
for (const f of files) {
  const { key } = keyFor(f.bytes, 'jpg');
  const fresh = !store.has(key);
  if (fresh) store.set(key, f.bytes);
  console.log(f.name.padEnd(14), key, fresh ? 'PUT' : 'skip (already stored)');
}
console.log('objects stored:', store.size, 'of', files.length, 'uploads');

// এক byte বদলালে hash পুরো বদলে যায়
const a = keyFor(Buffer.from('JPEG…ilish-pixels…v1'), 'jpg').hash;
const b = keyFor(Buffer.from('JPEG…ilish-pixels…v1 '), 'jpg').hash;
let same = 0;
for (let i = 0; i < 64; i++) if (a[i] === b[i]) same++;
console.log('hex chars equal after 1-byte change:', same, 'of 64');

আমাদের সত্যিকারের run-এ এই সুবিধা নিজে থেকেই দেখা দিল। একই ছবি POST আর PUT দুই পথে দুবার upload হয়েছিল। দুটি job-ই পেল একই hash cd3bd1229e378312, আর দ্বিতীয়টি একই key-তে একই byte লিখল। Storage দ্বিগুণ হয়নি।

৬ · Image pipeline — background job-এ sharp, srcset আর next/image

ছবি ছোট করা CPU-র কাজ, AVIF-এ আরও বেশি। এটি অনুরোধের ভেতরে করলে ব্যবহারকারী অপেক্ষা করেন, আর একসাথে অনেক upload এলে server ধীর হয়। তাই কাজটি যায় একটি background worker-এ। Queue, retry আর cron-এর পুরো নকশা পর্ব ৬২-এর বিষয়, আর তত্ত্ব System Design কোর্সের jobs পর্বে; এখানে আমরা PostgreSQL-এর একটি jobs টেবিলকেই সরল queue হিসেবে নিলাম।

const WIDTHS = [320, 480, 640, 960, 1280];
const FORMATS = { webp: { quality: 75 }, avif: { quality: 50 } };

async function claim() {                       // একটি job ধরা, অন্য worker-কে বাদ দিয়ে
  const { rows } = await pool.query(`
    update jobs set status = 'running', attempts = attempts + 1
    where id = (select id from jobs where status = 'queued'
                order by id for update skip locked limit 1)
    returning *`);
  return rows[0];
}

// variants(job)-এর ভেতরে:
const img = sharp(input, { limitInputPixels: 24_000_000 }).autoOrient();
for (const w of WIDTHS) for (const [fmt, opt] of Object.entries(FORMATS)) {
  const data = await img.clone().resize({ width: w, withoutEnlargement: true })[fmt](opt).toBuffer();
  await s3.send(new PutObjectCommand({ Bucket: MEDIA, Key: `products/${hash}/${w}.${fmt}`,
    Body: data, ContentType: `image/${fmt}`, CacheControl: 'public, max-age=31536000, immutable' }));
}

for update skip locked হলো ছোট কিন্তু জরুরি কৌশল: দুটি worker একসাথে চললে একজন যে সারি ধরেছে, অন্যজন সেটি এড়িয়ে পরেরটি নেয়, ফলে একই job দুবার চলে না। ব্যর্থ হলে attempts বাড়ে, তিনবারের পরে job “dead”. WebP আর AVIF দুটোই বানানো হলো, কারণ AVIF প্রায়ই ছোট, কিন্তু encode ধীর। নিচের stepper-এ worker-এর সত্যিকারের run, sharp 0.35.5 (libvips 8.18.7):

সংখ্যাগুলো একটি কৃত্রিম ছবির, যাতে gradient, কয়েকটি রঙিন আকার আর হালকা noise আছে। আসল ছবিতে অনুপাত আলাদা হবে; WebP না AVIF ভালো, সে সিদ্ধান্ত নিজের পণ্যের ছবিতে মেপে নিন। আসল ছবি রাখবেন কি না, তা-ও নীতির প্রশ্ন: রাখলে পরে নতুন মাপ বানানো যায়, না রাখলে storage আর ঝুঁকি কম। আমাদের worker মুছে দেয়।

কোন পর্দা কোন ফাইল নেবে — srcset আর sizes

পাঁচটি প্রস্থ বানানো অর্থহীন, যদি browser জানতে না পারে কোনটি নেবে। srcset বলে কোন ফাইল কত প্রস্থের, আর sizes বলে পাতায় ছবিটি কত CSS pixel জায়গা নেবে। Browser তারপর পর্দার device pixel ratio দিয়ে গুণ করে দরকারি pixel বের করে। পণ্যের তালিকায় আমাদের নকশা: ফোনে দুই কলাম, ট্যাবে তিন, বড় পর্দায় ৩০০px কার্ড।

// পণ্যের ছবির srcset পরিকল্পনা: কোন পর্দা কোন ফাইল নেবে
const WIDTHS = [320, 480, 640, 960, 1280];          // worker যে মাপগুলো বানায়
const id = 'a2f35604';
const srcset = (fmt) => WIDTHS.map((w) => `/img/${id}-${w}.${fmt} ${w}w`).join(', ');
const sizes = '(max-width: 640px) 50vw, (max-width: 1024px) 33vw, 300px';

// sizes-এর নিয়ম: প্রথম যে শর্ত মেলে, সেই CSS প্রস্থ
function slotWidth(vw) {
  if (vw <= 640) return vw * 0.5;
  if (vw <= 1024) return vw / 3;
  return 300;
}
// browser সাধারণত দরকারি pixel-এর সমান বা বড় সবচেয়ে ছোট মাপটি নেয়
const pick = (need) => WIDTHS.find((w) => w >= need) ?? WIDTHS.at(-1);

const screens = [
  { name: 'budget phone', vw: 360, dpr: 2 },
  { name: 'big phone', vw: 412, dpr: 3 },
  { name: 'tablet', vw: 800, dpr: 2 },
  { name: 'laptop', vw: 1366, dpr: 1 },
  { name: 'hi-dpi desktop', vw: 1920, dpr: 2 },
];
for (const s of screens) {
  const css = slotWidth(s.vw), need = Math.ceil(css * s.dpr);
  console.log(`${s.name.padEnd(15)} slot ${String(Math.round(css)).padStart(3)}px x${s.dpr} need ${String(need).padStart(4)} → ${pick(need)}w`);
}
console.log('srcset (avif):', srcset('avif').slice(0, 60) + '…');
console.log('sizes:', sizes);
console.log('files per product:', WIDTHS.length, 'widths x 2 formats =', WIDTHS.length * 2);

প্লেইন HTML-এ একাধিক ফরম্যাট দিতে <picture> লাগে: আগে AVIF-এর <source>, তারপর WebP, শেষে <img>. Browser প্রথম যে ধরন বোঝে, সেটি নেয়। অলস লোডিং আর জায়গা ধরে রাখার মতো বিষয় পর্ব ২৩-এ আর HTML & CSS কোর্সে আছে।

next/image আর নিজের loader

Next.js-এর next/image সাধারণত নিজেই ছবি ছোট করে (built-in optimizer). কিন্তু আমাদের worker আগেই মাপগুলো বানিয়ে রেখেছে, আর CDN থেকে সরাসরি দেওয়াই সস্তা। তাই loaderFile দিয়ে Next.js-কে জানাই যে সে শুধু URL বানাবে। Next.js 16.4.4-এর docs অনুযায়ী loader পায় { src, width, quality } আর একটি URL ফেরত দেয়:

export default {
  images: {
    loader: 'custom',
    loaderFile: './image-loader.js',
    imageSizes: [320, 480],          // deviceSizes-এর সবচেয়ে ছোটটির চেয়ে ছোট
    deviceSizes: [640, 960, 1280],   // worker ঠিক এই মাপগুলোই বানায়
  },
};

'use client';
const CDN = 'https://img.bazarghar.example';
const MADE = [320, 480, 640, 960, 1280];

export default function bazargharLoader({ src, width }) {
  const w = MADE.find((m) => m >= width) ?? MADE.at(-1);   // অজানা মাপ এলে কাছের বড়টি
  return `${CDN}/${src}-${w}.webp`;
}

import Image from 'next/image';

export default function Page() {
  return (
    <Image src="products/a2/a2f35604" alt="ইলিশ মাছ, ১ কেজি" width={1280} height={960}
      sizes="(max-width: 640px) 50vw, (max-width: 1024px) 33vw, 300px" />
  );
}

next build চালিয়ে তৈরি HTML থেকে <img>-টি বের করলাম। সত্যিকারের run, Next.js 16.4.4, দেখার সুবিধার জন্য attribute আলাদা লাইনে:

<img alt="ইলিশ মাছ, ১ কেজি" loading="lazy" width="1280" height="960"
  decoding="async" data-nimg="1" style="color:transparent"
  sizes="(max-width: 640px) 50vw, (max-width: 1024px) 33vw, 300px"
  srcSet="https://img.bazarghar.example/products/a2/a2f35604-320.webp 320w,
          https://img.bazarghar.example/products/a2/a2f35604-480.webp 480w,
          https://img.bazarghar.example/products/a2/a2f35604-640.webp 640w,
          https://img.bazarghar.example/products/a2/a2f35604-960.webp 960w,
          https://img.bazarghar.example/products/a2/a2f35604-1280.webp 1280w"
  src="https://img.bazarghar.example/products/a2/a2f35604-1280.webp"/>

imageSizes আর deviceSizes মিলিয়ে ঠিক আমাদের পাঁচটি প্রস্থই এসেছে, কারণ sizes দেওয়া থাকলে Next.js দুই তালিকা জুড়ে পূর্ণ srcset বানায়। Default তালিকা রাখলে loader 750 বা 828-এর মতো মাপ চাইত, যা worker বানায়নি; সেজন্যই loader-এ “কাছের বড়টি” নেওয়ার নিরাপত্তা। এই loader শুধু WebP দেয়। AVIF-ও চাইলে Next.js-এর getImageProps দিয়ে <picture> বানানো যায়, অথবা CDN Accept header দেখে ফরম্যাট বাছতে পারে। Remote ছবিতে Next.js-এর নিজের optimizer ব্যবহার করলে remotePatterns-এ ঠিকানা allowlist করতে হয়, আর Next.js 16 থেকে qualities-এর default [75]; বিস্তারিত পর্ব ৫৮-এর Open Graph ছবির আলোচনার পাশে রাখুন।

৭ · Private ফাইল বনাম public asset

সব ফাইল এক রকম নয়। পণ্যের ছবি সবার জন্য, বারবার পড়া হয়, কখনো বদলায় না (বদলালে নতুন key). চালানের PDF শুধু একজন ক্রেতার, মাঝেমধ্যে পড়া হয়, আর ফাঁস হলে নাম, ঠিকানা, ফোন নম্বর বেরিয়ে যায়। তাই দুটির জন্য দুটি bucket আর দুটি নিয়ম।

Public ছবি anonymous ভাবে পড়লাম, আর private bucket-এর চালান সই ছাড়া চাইলাম। সত্যিকারের run:

anon GET public products/cd3bd1229e378312/640.avif 200 content-type: image/avif | content-length: 8541
  | cache-control: public, max-age=31536000, immutable | etag: "ca2055d5bbfc05ea508c2550b166175b"
anon GET private invoice 403

Worker যে CacheControl লিখেছিল, store সেটিই header হিসেবে দিচ্ছে। CDN এই header দেখে এক বছর রাখবে, আর browser-ও আবার জিজ্ঞেস করবে না। এটি নিরাপদ শুধু এজন্য যে key-তে hash আছে; ছবি বদলালে key বদলায়, পুরোনো URL কখনো নতুন ছবি দেখায় না, তাই cache “মুছে ফেলার” দরকারই পড়ে না। CDN-এর ভেতরের কাজ System Design-এর CDN পর্বে, আর cache header-এর বিস্তারিত পর্ব ৮৪-এ।

চালান ডাউনলোড — স্বল্পমেয়াদি GET URL

app.get('/api/invoices/:id/download', requireLogin, async (req, res) => {
  const { rows: [inv] } = await pool.query('select * from invoices where id = $1', [req.params.id]);
  if (!inv || inv.owner_id !== req.user.id) return res.status(404).json({ error: 'NOT_FOUND' });
  const url = await getSignedUrl(s3, new GetObjectCommand({
    Bucket: PRIVATE, Key: inv.key,
    ResponseContentDisposition: `attachment; filename="${inv.id}.pdf"`,
    ResponseContentType: 'application/pdf',
  }), { expiresIn: 60 });
  res.set('Cache-Control', 'no-store').redirect(302, url);
});

GET /api/invoices/INV-1042/download

INV-1042  owner_id 17  key invoices/2026/11/INV-1042.pdf
user 17 → এগিয়ে যায়   user 18 → 404

302  Cache-Control: no-store
Location: /bazarghar-private/invoices/2026/11/
          INV-1042.pdf?…&X-Amz-Expires=60&…

200
content-type: application/pdf
content-disposition: attachment; filename="INV-1042.pdf"

403  AccessDenied — Request has expired

403  SignatureDoesNotMatch
সই ছাড়া সরাসরি → 403

মেয়াদের হিসাব store করে X-Amz-Date আর X-Amz-Expires থেকে। নিচের ছোট মডেলটি নকল ঘড়িতে সেই হিসাব দেখায়, সাথে ঘড়ি ভুলের একটি ফাঁদ:

// Presigned URL কখন অচল হয়: নকল ঘড়িতে store-এর হিসাব
const url = new URL('https://store.example.test/bazarghar-private/invoices/INV-1042.pdf' +
  '?X-Amz-Date=20261103T101500Z&X-Amz-Expires=300&X-Amz-Signature=0000example');

function parseAmzDate(s) {          // 20261103T101500Z → ms
  const [, y, mo, d, h, mi, se] = /^(\d{4})(\d\d)(\d\d)T(\d\d)(\d\d)(\d\d)Z$/.exec(s);
  return Date.UTC(+y, mo - 1, +d, +h, +mi, +se);
}

function check(u, nowMs) {
  const signedAt = parseAmzDate(u.searchParams.get('X-Amz-Date'));
  const expires = Number(u.searchParams.get('X-Amz-Expires'));
  if (!(expires >= 1 && expires <= 604800)) return 'REJECT bad expiry';   // ৭ দিন সর্বোচ্চ
  const left = Math.round((signedAt + expires * 1000 - nowMs) / 1000);
  return left > 0 ? `OK, ${left}s left` : `403 expired ${-left}s ago`;
}

const t0 = parseAmzDate('20261103T101500Z');
const clock = [0, 60, 299, 300, 301, 3600];          // সই-এর পর কত সেকেন্ড
for (const s of clock) console.log(`t+${String(s).padStart(4)}s`, check(url, t0 + s * 1000));

// app server-এর ঘড়ি ৪ মিনিট পিছিয়ে: সই-এর সময়ই ভুল লেখা হলো
const skewed = new URL(url);
skewed.searchParams.set('X-Amz-Date', '20261103T101100Z');
console.log('app clock -4 min, t+0s:', check(skewed, t0));
skewed.searchParams.set('X-Amz-Expires', '2592000');           // ৩০ দিন চাওয়া
console.log('asked 30 days:', check(skewed, t0));

সত্যিকারের store-এ ঘড়ির পরীক্ষাও করলাম। SDK-কে নকল সই-সময় দিয়ে (signingDate) ৩০০ সেকেন্ডের URL: ৩০ মিনিট আগের সময়ে সই করা URL পেল 403 Request has expired, আর ২০ মিনিট ভবিষ্যতের সময়ে সই করা URL আমাদের SeaweedFS-এ 200 পেল। ভবিষ্যতের তারিখ নিয়ে সব store একই আচরণ করে কি না, আমরা যাচাই করিনি। শিক্ষা হলো: server-এ NTP দিয়ে ঘড়ি মিলিয়ে রাখুন, যা clock skew-এর পুরোনো সমস্যা।

৮ · মোছা, মালিকহীন ফাইল আর lifecycle নিয়ম

সরাসরি upload-এ মালিকহীন ফাইল জন্মানোর পথ আরও বেশি। Presign হলো কিন্তু ফাইল আসেনি; ফাইল এলো কিন্তু “complete” আসেনি, কারণ ব্যবহারকারী tab বন্ধ করেছেন; app crash করল সারি লেখার আগে। আমাদের run-এর পরে PostgreSQL-এ চারটি pending সারি ছিল, যাদের ফাইল store আগেই ফিরিয়েছিল। তার সাথে আমরা ইচ্ছা করে একটি upload করে complete ডাকলাম না, আর একটি object রাখলাম যার কোনো সারিই নেই। তারপর pending সারিগুলোকে ২৫ ঘণ্টা পুরোনো করে দিলাম, ঘড়ি এগিয়ে নেওয়ার বদলে। পাহারাদার script আগে শুধু দেখে, তারপর মোছে। সত্যিকারের run:

$ node sweep.mjs
would mark only      incoming/14ab0bf8-0a4d-4064-b4c2-d3d6f817e078.jpg
would mark only      incoming/14d1f372-74ba-42ae-ba74-c7ce9a5a4212.jpg
would mark only      incoming/449c7ccd-8ed2-4d75-87eb-74bb3ae02669.jpg
would mark only      incoming/494dc256-e05e-4ff1-9832-2f674784621e.jpg
would delete object + mark incoming/34145076-d34f-4a3c-b112-fcb06f1254a6.jpg
keep (young) incoming/stray-after-crash.jpg 0.00h
{ dryRun: true, stalePending: 5, objectFound: 1, neverArrived: 4,
  unknownYoung: 1, unknownOld: 0 }
$ node sweep.mjs --delete
… একই তালিকা, "did" দিয়ে …
[ { status: 'abandoned', n: 5 }, { status: 'ready', n: 2 }, { status: 'rejected', n: 1 } ]

পাহারাদার দুই দিক থেকে খোঁজে। Database থেকে: ২৪ ঘণ্টার পুরোনো pending সারি, যার জন্য store-কে জিজ্ঞেস করে ফাইল আছে কি না। Store থেকে: incoming/-এর এমন object, যার কোনো সারি নেই। stray-after-crash.jpg সারিহীন, কিন্তু মাত্র লেখা, তাই বেঁচে গেল; সারি তৈরির আগের মুহূর্তের চলমান upload মুছে ফেলার ঝুঁকি এই ছাড়ের সময় ঠেকায়। এই কাজটি নিয়মিত চালানো একটি cron job, যার নকশা পর্ব ৬২-এ।

Lifecycle নিয়ম — store নিজেই পরিষ্কার করুক

যেখানে পারা যায়, পরিষ্কারের কাজ store-কে দিন। আমরা private bucket-এ দুটি নিয়ম বসিয়ে ফেরত পড়লাম। সত্যিকারের run:

lifecycle: [{"Status":"Enabled","Expiration":{"Days":1},"ID":"incoming-1-day","Filter":{"Prefix":"incoming/"}},
 {"Status":"Enabled","ID":"abort-multipart","Filter":{"Prefix":""},"AbortIncompleteMultipartUpload":{"DaysAfterInitiation":2}}]

প্রথমটি incoming/-এর যেকোনো object এক দিন পরে মোছে। Worker সফল ছবিকে অন্য bucket-এ সরিয়ে নেয়, তাই incoming/-এ যা পড়ে থাকে তা সংজ্ঞা অনুযায়ীই আবর্জনা। দ্বিতীয়টি বড় ফাইলের অসম্পূর্ণ S3 multipart upload-এর টুকরো মোছে, যা তালিকায় সাধারণত দেখা যায় না কিন্তু জায়গা নেয়। একটি সতর্কতা: নিয়মটি store গ্রহণ করেছে আর ফেরত দিয়েছে, কিন্তু এক দিন অপেক্ষা করে মুছে যাওয়া আমরা নিজে দেখিনি। প্রতিটি provider-এ lifecycle-এর কোন অংশ সত্যিই চলে, আর কত দেরিতে চলে, তা তাদের docs-এ দেখে নিন; database-এর পাহারাদার তাই থাকছেই।

মোছার ক্রম পর্ব ৩০-এর মতোই: আগে database সারি, পরে object. ভাঙলে বাড়তি object থাকে, যা পাহারাদার ধরবে; ভাঙা লিংক থাকে না। পণ্য মুছলে তার দশটি variant-ও মোছার job হবে। Versioning চালু থাকা bucket-এ “মোছা” মানে একটি delete marker বসানো, পুরোনো সংস্করণ থেকে যায়; তখন lifecycle-এ পুরোনো সংস্করণ মোছার নিয়মও লাগে। ব্যবহারকারী তার অ্যাকাউন্ট মুছতে বললে backup আর পুরোনো সংস্করণেও কী থাকছে, তা গোপনীয়তার নীতিতে লিখে রাখুন।

৯ · খরচ, provider আর lock-in এড়ানো

Object storage-এর বিল সাধারণত তিন ভাগে: রাখা (GB-মাস), অনুরোধ (প্রতি হাজার PUT বা GET) আর বাইরে যাওয়া ডেটা, যাকে বলে egress. অনেকে শুধু প্রথমটি দেখেন। একটি পূর্ণ হিসাব করি। এখানে সব দাম অনুমান, কোনো provider-এর আসল দাম নয়: রাখা ২ টাকা প্রতি GB-মাস, egress ১০ টাকা প্রতি GB. অনুরোধের খরচ বাদ।

তিনটি শিক্ষা। প্রথমত, এই অনুমানে egress রাখার খরচের প্রায় ৬৬ গুণ। দ্বিতীয়ত, ঠিক মাপের ছবি দেওয়াই সবচেয়ে বড় সঞ্চয়: একই দর্শকে ৬১ GB বনাম প্রায় ৫ TB. তৃতীয়ত, CDN-এর cache hit rate ৯৫% হলে store থেকে বাইরে যায় মাত্র ৫%, প্রায় ৩.১ GB; বাকিটা CDN-এর বিলে, যার দাম আলাদা চুক্তির। আসল সংখ্যার জন্য provider-এর বর্তমান দামের পাতা দেখে নিজের হিসাব বসান; দাম আর বিনামূল্যের সীমা প্রায়ই বদলায়।

S3-সামঞ্জস্যপূর্ণ provider আর lock-in

S3 API এখন কার্যত একটি সাধারণ ভাষা। Amazon S3 নিজে (২০০৬ সালে চালু), Cloudflare R2, Backblaze B2-এর S3-সামঞ্জস্যপূর্ণ API, বড় cloud-গুলোর নিজস্ব object storage, আর নিজে চালানোর সফটওয়্যার, যেমন আমাদের SeaweedFS, সবাই কমবেশি একই SDK মেনে নেয়। কয়েকটি provider egress-এ দাম না নেওয়ার কথা ঘোষণা করেছে, যেমন লেখার সময়ে R2; শর্তগুলো তাদের নিজস্ব পাতায় পড়ে নিন। বাংলাদেশের কিছু ডেটা সেন্টার আর cloud সেবাও object storage দেওয়ার কথা বলে; দেশের ভেতরে latency কম হতে পারে, আর কিছু প্রতিষ্ঠানের ডেটা দেশে রাখার নিয়মও থাকতে পারে। কেনার আগে তাদের docs-এ যাচাই করুন কোন S3 অপারেশন সত্যিই চলে: presigned POST, bucket CORS, lifecycle, versioning. আমরা এখানে কোনো provider সুপারিশ করছি না।

• মানসম্মত API-তে থাকুন: SDK-এর সাধারণ অপারেশন, endpoint config দিয়ে বদলানো যায় এমন। Provider-এর বিশেষ feature ব্যবহার করলে জেনে-বুঝে, এক জায়গায় আবদ্ধ রাখুন।
• এক জায়গায় storage-এর কোড: storage.putVariant(), storage.signInvoice()-এর মতো ছোট module, যাতে বদলাতে হলে একটি ফাইল বদলায়। পর্ব ২৯-এর service স্তরের ধারণা।
• Key আর URL আপনার: Database-এ রাখুন key, পুরো provider URL নয়। CDN-এর domain নিজের রাখুন, যেমন img.bazarghar.example, যাতে পেছনের store বদলালেও HTML-এর লিংক ভাঙে না।
• সরে যাওয়ার খরচ মাপুন: ৫ TB সরাতে পুরোনো provider-এর egress লাগে। আগেই হিসাব করে রাখলে চুক্তির সময় দর কষাকষি সহজ।
• নিজে চালানোর ঝুঁকি: MinIO-র archive হওয়া দেখায়, open-source প্রকল্পেরও দিক বদলায়। নিজে চালালে update, backup আর বিকল্পের পরিকল্পনা আপনার দায়িত্ব। চালানোর দিক Cloud & DevOps কোর্সে.

১০ · AI-এর যুগে file storage

S3-এর কোড ইন্টারনেটে বিপুল, আর তার বড় অংশ পুরোনো SDK v2-এর। তাই AI দ্রুত কোড দেয়, কিন্তু প্রায়ই পুরোনো API, খোলা bucket আর লম্বা মেয়াদ নিয়ে।

AI-এর লেখা storage কোডের চেকলিস্ট

• প্রতিটি package আর option সেই version-এর docs-এ খুঁজে পেয়েছি; SDK v2 বা অচেনা package নেই
• নিজের local store-এ সত্যিকারের upload চালিয়েছি, শুধু “compile হলো” দেখে থামিনি
• বড় ফাইল, ভুল ধরন, অন্য origin আর মেয়াদ শেষের ঘটনায় ঠিক 4xx পেয়েছি
• incoming/ আর private bucket সই ছাড়া খোলা যায় না, নিজে চেষ্টা করে দেখেছি
• কোনো secret কোডে, client bundle-এ বা AI-এর chat-এ নেই; উদাহরণে নকল মান
• Diff পড়েছি, catch error গিলে ফেলছে না, আর complete ও sweep-এর test লিখেছি