একটি অ্যাপ বড় করা — ১০০ থেকে ১০ লাখ ব্যবহারকারী

১ · বাজারঘরের গল্প — আর একটিই নিয়ম: আগে মাপুন

এই কোর্সজুড়ে আপনি “বাজারঘর” বানিয়েছেন: পণ্যের তালিকা, কার্ট, অর্ডার, login, email, ছবি, chat, payment. এবার একটি কল্পনা করুন। দোকানটি চালু হলো, প্রথম মাসে ১০০ জন ক্রেতা। তারপর কয়েক বছরে ১০ লাখ। পথে প্রতিটি ধাপে কিছু না কিছু ভাঙে, আর দলকে বেছে নিতে হয় কী বদলাবে। এই পর্ব সেই পথের একটি সৎ গল্প।

বড় কোম্পানির scaling-এর তত্ত্ব আর case study ABCL TECH-এর System Design কোর্স-এর বিষয়: vertical বনাম horizontal scaling, খামের পেছনের হিসাব, replication, partitioning, monolith বনাম microservices. এখানে সেগুলো আবার শেখানো হবে না। এখানে প্রশ্ন একটু আলাদা: একটি ছোট ফুল-স্ট্যাক দল, যাঁরা এই কোর্সের টুল দিয়ে অ্যাপ বানিয়েছেন, বাস্তবে কোন দিন কী বদলান, আর কেন।

প্রতিটি ধাপ আমরা একই ছকে দেখব:

নিচের stepper পুরো পথের মানচিত্র। প্রতিটি ধাপে কোন অংশ নতুন এল, তা দেখুন; বাকিটা আগের ধাপ থেকে থেকে গেছে। “পরে” চাপুন।

ক্রেতা ──HTTPS──▶ Caddy (TLS)
                    │
                    ▼
              Node (Next.js + API)  ১টি process, pm2
                    │
                    ▼
              PostgreSQL           একই VPS-এ
রোজ রাতে pg_dump → অন্য জায়গায় backup

CDN ◀── ছবি, JS, CSS (hash নাম, immutable)
ক্রেতা ──▶ Caddy ──▶ Node (১টি)
                       │        └──▶ Redis queue ──▶ worker (email)
                       ▼
                 PostgreSQL + index
N+1 সারানো, query log চালু

CDN ◀── object storage (পণ্যের ছবি)
ক্রেতা ──▶ Caddy ──┬──▶ Node 1 ─┐
                  ├──▶ Node 2 ─┼──▶ Redis (session, queue)
                  └──▶ Node 3 ─┘
                         │ pool: প্রতিটিতে ৫
                         ▼
               PostgreSQL (নিজের VPS)
monitoring: metric, error, SLO

CDN ──▶ load balancer ──▶ app server × ৩ (প্রতিটিতে ৪ process)
                              │
          Redis ◀─────────────┼──▶ cache-aside + lock
          (session, queue,    │    Socket.IO adapter
           rate limit)        ▼
         PostgreSQL primary ──WAL──▶ read replica
              ▲ লেখা, checkout       (তালিকা, রিপোর্ট)
অর্ডারের queue → worker (ঈদের ঢেউ)

modular monolith: catalog │ orders │ accounts │ payments
        │ (module-এর সীমা কোডে, এক deploy)
        ├──▶ search service (আলাদা index)
        └──▶ notification service (email, SMS, push)
PostgreSQL: orders মাস ধরে partition
            ২ বছরের পুরোনো → archive
দ্বিতীয় region: শুধু backup আর দুর্যোগের প্রস্তুতি

২ · ক্ষমতার হিসাব — দৈনিক ব্যবহারকারী থেকে req/s, connection আর GB

“১০ লাখ ব্যবহারকারী” শুনে ভয় লাগে, কিন্তু সংখ্যাটি নিজে কিছু বলে না। Server চেনে প্রতি সেকেন্ডের অনুরোধ, প্রতি সেকেন্ডের SQL, একসাথে খোলা connection আর disk-এর GB. তাই প্রথম কাজ capacity planning: ব্যবহারকারীর সংখ্যাকে এই ভাষায় অনুবাদ করা। পদ্ধতির পুরো তত্ত্ব System Design-এর estimation পর্বে আছে; এখানে বাজারঘরের সংখ্যায় চারটি সূত্র।

ধরে নেওয়া সংখ্যাগুলো কোডের ওপরে লেখা আছে; প্রতিটি নিজের মতো বদলে আবার চালান। মনে রাখুন, এগুলো অনুমান। আসল দোকানে প্রথম দিন থেকেই log থেকে এই সংখ্যা মাপা যায় (পর্ব ৩১), আর তখন অনুমানের জায়গায় মাপ বসে।

// শিক্ষণ মডেল: দৈনিক ব্যবহারকারী থেকে peak req/s, SQL আর storage
// সব সংখ্যা ধরে নেওয়া; নিজের মাপা মান বসিয়ে আবার চালান
const REQ_PER_USER = 30;   // একজনের দিনে HTML আর API অনুরোধ (ছবি, JS CDN থেকে)
const PEAK = 5;            // রাত ৯টার ভিড়: দিনের গড়ের ৫ গুণ
const SQL_PER_REQ = 3;     // প্রতি অনুরোধে গড়ে ৩টি SQL (cache ছাড়া)
const ORDERS_PER_USER = 0.04; // দিনে ১০০ জনে ৪টি অর্ডার
const KB_PER_ORDER = 4;    // order, item, index আর audit মিলিয়ে

function capacity(dau) {
  const avg = (dau * REQ_PER_USER) / 86400;   // দিনে ৮৬,৪০০ সেকেন্ড
  const peak = avg * PEAK;
  const sql = peak * SQL_PER_REQ;
  const ordersYear = dau * ORDERS_PER_USER * 365;
  const gbYear = (ordersYear * KB_PER_ORDER) / (1024 * 1024);
  return { avg, peak, sql, ordersYear, gbYear };
}

console.log("DAU       avg r/s  peak r/s  peak SQL/s  orders/yr   GB/yr");
for (const dau of [100, 1000, 10000, 100000, 1000000]) {
  const c = capacity(dau);
  console.log(
    String(dau).padEnd(9),
    c.avg.toFixed(2).padStart(8),
    c.peak.toFixed(1).padStart(9),
    Math.round(c.sql).toString().padStart(11),
    Math.round(c.ordersYear).toString().padStart(10),
    c.gbYear.toFixed(2).padStart(7)
  );
}
const eid = capacity(100000).avg * 20;     // ঈদের সেলের প্রথম ঘণ্টা: গড়ের ২০ গুণ
console.log("Eid peak at 1 lakh DAU:", eid.toFixed(0), "r/s");

Peak factor কোথা থেকে আসে? ঘণ্টা ধরে অনুরোধের সংখ্যার একটি graph থেকে: সবচেয়ে ব্যস্ত মিনিটের হার ÷ দিনের গড় হার। নতুন দোকানে এটি প্রায়ই বড়, কারণ অল্প ক্রেতা একই সময়ে আসেন (একটি পোস্টের পরে); বড় দোকানে ভিড় ছড়ায়, কিন্তু উৎসব নতুন চূড়া আনে। Latency আর throughput-এর পর্বে দেখেছেন গড় কেন লুকায়; এখানেও একই কথা।

Little-এর সূত্র দিয়ে connection pool

Connection pool (পর্ব ৩৮) কতটা বড় হবে, অনুমানে নয়, সূত্রে বের হয়। ব্যাংকের কাউন্টারে প্রতি মিনিটে ৬ জন আসেন, আর প্রতিজন ২ মিনিট থাকেন: গড়ে কাউন্টারে ৬ × ২ = ১২ জন। এটিই L = λ × W. Database-এর ক্ষেত্রে λ মানে প্রতি সেকেন্ডের SQL, W মানে একটি SQL কত সেকেন্ড connection ধরে রাখে, আর L মানে গড়ে কতটি connection ব্যস্ত।

// শিক্ষণ মডেল: Little-এর সূত্র L = λ × W দিয়ে connection pool-এর মাপ
// λ = প্রতি সেকেন্ডে কতটি SQL, W = একটি SQL কত সেকেন্ড connection ধরে রাখে
const busy = (sqlPerSec, msPerQuery) => sqlPerSec * (msPerQuery / 1000);

// ১. মাপা run যাচাই: autocannon-এর ৫০টি সংযোগ, গড়ে 291 req/s
console.log("lab: W = L / λ =", (50 / 291 * 1000).toFixed(0), "ms per request");

// ২. peak SQL/s (ক্যালকুলেটর থেকে) আর একটি SQL-এর সময়, দুটিই বদলে দেখুন
const cases = [
  ["10k DAU, 4 ms", 52, 4],
  ["1 lakh DAU, 4 ms", 521, 4],
  ["Eid peak, 4 ms", 2083, 4],
  ["Eid peak, 40 ms (index নেই)", 2083, 40],
];
for (const [name, sql, ms] of cases) {
  const L = busy(sql, ms);
  console.log(`${name.padEnd(28)} busy ${L.toFixed(1).padStart(5)}  pool with 2x headroom ${Math.ceil(L * 2)}`);
}

// ৩. সব process মিলিয়ে কতটি connection চাওয়া হচ্ছে
const LIMIT = 100 - 3;   // PostgreSQL ডিফল্ট max_connections 100, ৩টি superuser-এর জন্য
for (const [servers, procs, pool] of [[1, 4, 10], [3, 4, 10], [3, 4, 5]]) {
  const want = servers * procs * pool;
  console.log(`${servers} server × ${procs} process × pool ${pool} = ${want} -> ${want <= LIMIT ? "OK" : "too many"}`);
}

৩ · ধাপ ১: ১০০ জন — একটি VPS, একটি process, একটি PostgreSQL

প্রথম মাসে বাজারঘরের দল দুজন। একটি ছোট VPS (ধরে নেওয়া: ২টি vCPU, ৪ GB RAM), তাতে পর্ব ৮২-এর মতো output: 'standalone'-এর Next.js build, pm2, সামনে Caddy, আর একই মেশিনে PostgreSQL. ক্যালকুলেটর বলছে peak-এ ০.২ req/s; এই মেশিন তার শত গুণ সামলাবে।

এই ধাপে সবচেয়ে দামি সিদ্ধান্তগুলো কিন্তু scaling-এর নয়, ডেটার। টাকা পয়সায় (minor unit) রাখা (পর্ব ৩৯), অর্ডারে দামের snapshot, প্রতিটি টেবিলে primary key আর foreign key, payment-এ idempotency key (পর্ব ৬৫), আর migration দিয়ে schema বদল (পর্ব ৪০)। দশ লাখে গিয়ে server বদলানো সহজ, ভুল ডেটা মডেল বদলানো খুব কঠিন।

৪ · ধাপ ২: ১,০০০ জন — index আর N+1, CDN, background job

ছয় মাস পরে প্রথম অভিযোগ: “আমার অর্ডার” পাতা খুলতে দেরি হয়। দল অনুমান করেনি; পর্ব ৩১-এর structured log থেকে route ধরে সময় বের করেছে। কল্পিত graph-এ GET /api/customers/:id/orders-এর p95 ধীরে ধীরে বাড়ছে, অর্ডারের সংখ্যার সাথে সাথে। একই সময়ে checkout-এর p50 অর্ধেক সেকেন্ডের বেশি, কারণ অর্ডার নিশ্চিতের email একই request-এ যায়।

একটি আসল load test: index আর cache, একটি একটি করে

“Index দিলে কতটা লাভ” কথায় নয়, মেপে দেখা যাক। এই পর্বের ল্যাবে একটি ছোট Express app: একটিই endpoint, যা একজন ক্রেতার সর্বশেষ ২০টি অর্ডার আনে, PostgreSQL-এর orders table-এ ৫ লাখ সারি আর ৫০ হাজার ক্রেতা। Load দিয়েছে autocannon, একটি Node-ভিত্তিক load test টুল। লেখার সময়ের version: Node 24.15.0, Express 5.3.0, pg 8.23.1, autocannon 8.0.0, আর embedded-postgres 18.6.0-beta.19 (PostgreSQL 18.6; এই npm package-এর সব release-এর নামেই -beta থাকে)। সবকিছু চলেছে 127.0.0.1-এ, একটিই ল্যাপটপে।

const pool = new pg.Pool({ host: '127.0.0.1', port: 54887,
  database: 'bazarghar_p87', user: 'postgres', password: 'example-secret', max: 10 });
const USE_CACHE = process.env.CACHE === '1';
const cache = new Map();                 // ল্যাবে process-এর ভেতরের cache, TTL 30 s

app.get('/api/customers/:id/orders', async (req, res) => {
  const id = Number(req.params.id);
  if (!Number.isInteger(id) || id < 1) return res.status(400).json({ error: 'bad id' });
  const key = `orders:${id}`;
  if (USE_CACHE) {
    const c = cache.get(key);
    if (c && Date.now() - c.at < 30_000) { stats.hits++; return res.json(c.value); }
  }
  stats.dbQueries++;
  const { rows } = await pool.query(
    'SELECT id, status, total, created_at FROM orders WHERE customer_id = $1 ORDER BY created_at DESC LIMIT 20',
    [id]);
  if (USE_CACHE) cache.set(key, { at: Date.now(), value: rows });
  res.json(rows);
});

Load-এর ধরন: ৫০টি একসাথে চলা সংযোগ, ১০ সেকেন্ড; প্রতিটি অনুরোধের ক্রেতা একটি seeded PRNG থেকে, ৮০% অনুরোধ ২,০০০ জন “নিয়মিত” ক্রেতার মধ্যে আর ২০% সব ৫০ হাজারের মধ্যে। চারটি অবস্থা: index ছাড়া আর সহ, cache ছাড়া আর সহ। প্রতিটির আগে একই query-র EXPLAIN ANALYZE. সত্যিকারের run, একবার, ছাঁটা:

server: { db: 'bazarghar_p87', port: '54887', v: '18.6' }
rows: { n: 500000, c: 50000 }

== A: no index, no cache
  ->  Parallel Seq Scan on orders  (cost=0.00..6621.17 rows=4 width=28) (actual time=0.405..5.173 rows=3.33 loops=3)
  Execution Time: 17.899 ms
  req/s avg 291  latency p50 142 ms  p99 457 ms  non2xx 0  errors 0  total 2910
  app stats: {"requests":2960,"dbQueries":2960,"hits":0}  hit rate 0.0%

== B: index, no cache
  ->  Bitmap Heap Scan on orders  (cost=4.50..43.13 rows=10 width=28) (actual time=0.083..0.093 rows=10.00 loops=1)
  ->  Bitmap Index Scan on orders_customer_created  (cost=0.00..4.50 rows=10 width=0) (actual time=0.068..0.068 rows=10.00 loops=1)
  Execution Time: 0.127 ms
  req/s avg 10485.5  latency p50 3 ms  p99 14 ms  non2xx 0  errors 0  total 104847
  app stats: {"requests":104897,"dbQueries":104897,"hits":0}  hit rate 0.0%

== C: no index, cache
  ->  Parallel Seq Scan on orders  (cost=0.00..6621.17 rows=4 width=28) (actual time=0.801..10.157 rows=3.33 loops=3)
  Execution Time: 125.384 ms
  req/s avg 468.3  latency p50 143 ms  p99 415 ms  non2xx 0  errors 0  total 4683
  app stats: {"requests":4733,"dbQueries":2692,"hits":2041}  hit rate 43.1%

== D: index + cache
  …  Execution Time: 0.127 ms
  req/s avg 12364  latency p50 3 ms  p99 13 ms  non2xx 0  errors 0  total 123639
  app stats: {"requests":123689,"dbQueries":20683,"hits":103006}  hit rate 83.3%

চারটি শিক্ষা, প্রতিটি এই একটি run থেকে।

• Index-ই আসল ওষুধ। A থেকে B: query seq scan-এ পুরো table পড়ছিল, index-এ সরাসরি ১০টি সারি। req/s ২৯১ থেকে ১০,৪৮৬ (প্রায় ৩৬ গুণ), p50 ১৪২ থেকে ৩ ms. কোনো নতুন server লাগেনি।
• Index ছাড়া cache সমস্যা লুকায়, সারায় না। C-তে req/s ২৯১ থেকে ৪৬৮, কিন্তু p50 ১৪৩ ms, একটুও নড়েনি; কারণ প্রতিটি miss এখনো ধীর, আর ধীর miss-এর জন্য cache ১০ সেকেন্ডে গরমই হতে পারেনি (hit rate ৪৩.১%). নতুন ক্রেতা, মেয়াদ শেষ হওয়া key আর restart-এর পরের প্রতিটি অনুরোধ এই ধীর পথেই যায়।
• Index-এর পরে cache ডেটাবেসের ভার কমায়। B থেকে D-তে req/s মাত্র ১৮% বাড়ল, কিন্তু ডেটাবেসে query ১,০৪,৮৯৭ থেকে ২০,৬৮৩: ৮০% কম। Cache-এর আসল কাজ এখানে latency নয়, database-কে বাঁচানো।
• Hit rate-এর ছাদ ঠিক করে traffic-এর ধরন। D-তে ৮৩.৩%: ৮০% অনুরোধ ২,০০০ জনের মধ্যে, তাঁরা দ্রুত cache-এ ওঠেন; বাকি ২০% ছড়ানো ৫০ হাজারে, তাঁদের প্রায় সবাই miss. TTL বা মেমরি বাড়ালেও এই ছাদ সামান্যই সরবে।

N+1-এর গল্প একই রকম: পর্ব ৪২-এর একটি local run-এ ২০টি অর্ডারের পাতায় ৪১টি SQL নেমেছিল ৩টিতে, আর network-এ ৪০ ms RTT থাকলে সেটাই ১,৬৭৩ ms থেকে ৪২ ms. আর email: পর্ব ৬২-এর একটি run-এ checkout-এর p50 ৫১৫ ms থেকে ০.৭ ms, শুধু email-কে request-এর বাইরে পাঠিয়ে। এই ধাপের তিনটি পরিবর্তনই কোনো নতুন server ছাড়া।

৫ · ধাপ ৩: ১০,০০০ জন — কয়েকটি process, Redis-এ session, object storage আর SLO

দেড় বছর পরে তিনটি নতুন লক্ষণ, তিনটিই কল্পিত graph থেকে। রাত ৯টায় Node process-এর CPU ১০০%-এ আটকে থাকে, অথচ VPS-এর বাকি তিনটি core প্রায় ফাঁকা। প্রতিটি deploy-এ কয়েক সেকেন্ড 502. আর disk ৮০% ভরা, কারণ বিক্রেতাদের তোলা ছবি VPS-এর uploads/ folder-এ।

এই ধাপের মূল শব্দ stateless. কয়েকটি process-এর সামনে reverse proxy বা load balancer বসালে একজন ক্রেতার পরপর দুটি অনুরোধ দুটি ভিন্ন process-এ যেতে পারে। তাই process-এর মেমরিতে যা থাকে (session, upload-এর ফাইল, cron-এর দায়িত্ব) তা বাইরে নিতে হয়। Sticky session আপাতত বাঁচায়, কিন্তু process মরলে সেই ক্রেতারা তবুও logout হন। কেন stateless ভালো, তার তত্ত্ব System Design-এর stateless পর্বে; load balancing-এর algorithm load balancing পর্বে।

প্রথম SLO: কী মাপলে বোঝা যায় দোকান ভালো চলছে

এই ধাপে প্রথমবার দল একটি SLO লেখে। কল্পিত উদাহরণ: “২৮ দিনের মধ্যে checkout-এর ৯৯.৫% অনুরোধ সফল আর ৮০০ ms-এর ভেতরে।” তাহলে ভুলের সুযোগ (error budget) ০.৫%. মাসে ধরুন ৪ লাখ checkout-এর অনুরোধ হলে ২,০০০টি পর্যন্ত খারাপ হতে পারে। Budget দ্রুত খরচ হলে feature থামিয়ে নির্ভরযোগ্যতার কাজ, অক্ষত থাকলে feature. কখন scale করবেন, তা বলে SLO, অনুভূতি নয় (পর্ব ৮৩; গভীরে System Design-এর observability পর্ব)।

৬ · ধাপ ৪ক: ১ লাখ জন — read replica আর stampede-এর পাহারাসহ cache

তিন বছরে বাজারঘর ১ লাখ দৈনিক ব্যবহারকারী। এখন app server তিনটি, একটি load balancer-এর পেছনে। নতুন লক্ষণ database-এ: কল্পিত graph-এ রাত ৯টায় PostgreSQL-এর CPU ৮৫%, সবচেয়ে বেশি সময় খায় ক্যাটাগরির তালিকা আর বিক্রেতাদের মাসিক রিপোর্ট। Slow query log বলছে রিপোর্টের একটি query একাই কয়েক সেকেন্ড ধরে চলে, আর তখন checkout-এর p95 লাফ দেয়।

Read-after-write: নতুন ঠিকানা কোথায় গেল?

Replica primary-র লেখার log (WAL) পেয়ে নিজে প্রয়োগ করে, কিন্তু সামান্য দেরিতে; সাধারণত মিলিসেকেন্ডে, ভারী লেখার সময় সেকেন্ডেও। সমস্যা হয় যখন একজন ক্রেতা লিখে সাথে সাথে নিজের লেখা পড়তে চান। নিচের stepper-এ lag ৩০০ ms ধরা হয়েছে (শিক্ষণ মডেল)।

1POST /addresses → primary: INSERT2primary → replica: WAL পথে (lag 300 ms)3303 → GET /addresses → replica4replica: পুরোনো তালিকা ফেরত5সংশোধন: লেখার পরে ৫ s primary-তে পড়া6GET /addresses → primary: নতুন তালিকা

আরও পথ: নিজের ডেটা (প্রোফাইল, কার্ট) সবসময় primary থেকে, বা lag বেশি হলে primary-তে ফেরা। কোন নিশ্চয়তা কেন, তার পুরো আলোচনা System Design-এর replication পর্বে (read-your-writes, monotonic reads). নিচের কোডটি একটি উদাহরণ, চালানো হয়নি; ধারণাটি দেখানোর জন্য:

// উদাহরণ (চালানো হয়নি): কোন পড়া কোন database-এ
export function dbFor(req, kind) {
  if (kind === 'write') return primary;
  const recent = req.session.wroteAt && Date.now() - req.session.wroteAt < 5000;
  if (recent || kind === 'own-data') return primary;   // নিজের লেখা নিজে দেখবেন
  return replica;                                        // তালিকা, রিপোর্ট, খোঁজা
}
// লেখার পরে: req.session.wroteAt = Date.now();

Cache hit rate কত হলে database বাঁচে

অংশ ৪-এর run-এ দেখেছেন cache ডেটাবেসে যাওয়া কমায়। কিন্তু কতটা hit rate লাগবে? উল্টো দিক থেকে হিসাব করুন: database আরামে কত SQL/s নিতে পারে (এটি নিজের load test আর graph থেকে আসে; এখানে ধরে নেওয়া), আর peak-এ কত আসবে।

// শিক্ষণ মডেল: cache hit rate ডেটাবেসের চাপ কতটা কমায়
// ধরে নেওয়া: ঈদের peak-এ 694 req/s × 3 SQL = 2,083 SQL/s, সবই cache করা যায় এমন পড়া
const PEAK_SQL = 2083;
const DB_BUDGET = 600;   // primary-কে আরামে রাখতে যত SQL/s, ধরে নেওয়া

console.log("hit rate   SQL/s to DB   vs budget");
for (const h of [0, 0.5, 0.7, 0.8, 0.9, 0.95, 0.99]) {
  const db = PEAK_SQL * (1 - h);
  const mark = db <= DB_BUDGET ? "OK" : "over";
  console.log(`${(h * 100).toFixed(0).padStart(4)}%   ${db.toFixed(0).padStart(11)}   ${mark}`);
}

// উল্টো প্রশ্ন: budget-এ থাকতে কত hit rate লাগবে?
const need = 1 - DB_BUDGET / PEAK_SQL;
console.log("needed hit rate:", (need * 100).toFixed(1) + "%");

// 90% থেকে 95% মানে miss অর্ধেক; 95% থেকে 99% মানে miss পাঁচ ভাগের এক ভাগ
const miss = (h) => 1 - h;
console.log("miss ratio 90->95:", (miss(0.95) / miss(0.9)).toFixed(2),
            " 95->99:", (miss(0.99) / miss(0.95)).toFixed(2));

// বাজারঘরের মাপা run D: ১,২৩,৬৮৯ অনুরোধে ২০,৬৮৩টি গেল ডেটাবেসে
console.log("lab run D hit rate:", ((1 - 20683 / 123689) * 100).toFixed(1) + "%");

Stampede এই ঝুঁকিরই ছোট রূপ: একটি জনপ্রিয় key-এর মেয়াদ শেষ হলে একই মুহূর্তে শত অনুরোধ miss পায় আর সবাই database-এ যায়। পর্ব ৪৪-এর একটি run-এ ৮ সেকেন্ডে একটি key-এর জন্য ২৪০ বার database, Redis lock দিয়ে ৪ বার। সাথে TTL-এ একটু এলোমেলো যোগ (jitter), যাতে সব key একসাথে শেষ না হয়। কৌশলগুলোর তত্ত্ব System Design-এর eviction আর invalidation পর্বে।

৭ · ধাপ ৪খ: ঈদের সেল — queue, rate limit আর কয়েকটি server-এ WebSocket

গত বছরের ঈদের সেলের কল্পিত postmortem: রাত ৮টায় সেল শুরু, প্রথম ১০ মিনিটে checkout-এর অনুরোধ স্বাভাবিকের প্রায় ৮ গুণ, database-এর connection শেষ, ২০ মিনিট ধরে 502, আর কিছু ক্রেতার টাকা কাটা গেলেও অর্ডার তৈরি হয়নি। Payment-এর অংশ পর্ব ৬৫-এর idempotency আর reconciliation দিয়ে সারানো হয়েছে। এবার ভিড়ের অংশ।

Queue কেন সাহায্য করে? কারণ database একটি নির্দিষ্ট গতিতেই নিরাপদে অর্ডার বানাতে পারে (stock-এর row lock, transaction). ঢেউ এলে সেই গতি বাড়ে না; queue ঢেউটিকে সময়ের ওপর ছড়িয়ে দেয়, যেমন মেট্রো স্টেশনের লাইন ভিড়কে প্ল্যাটফর্মে পৌঁছানোর আগেই সাজিয়ে দেয়। নিচের মডেলে worker সেকেন্ডে ২০০টি অর্ডার শেষ করে, queue-তে সর্বোচ্চ ৩,০০০টি জমতে পারে, আর সেল চলে t = ১০ থেকে ১৯ সেকেন্ড, সেকেন্ডে ৬০০টি করে (সব ধরে নেওয়া)।

// শিক্ষণ মডেল: ঈদের সেলে অর্ডারের ঢেউ, queue আর স্থির গতির worker
// কৃত্রিম ঘড়ি: প্রতিটি ধাপ ১ সেকেন্ড; কোনো এলোমেলো সংখ্যা নেই
const WORKER_RATE = 200;   // worker প্রতি সেকেন্ডে কতটি অর্ডার শেষ করে
const MAX_DEPTH = 3000;    // এর বেশি জমলে নতুন অর্ডার নয়: 429, একটু পরে চেষ্টা
function arrivals(t) {     // রাত ৮টায় সেল শুরু: t=10 থেকে 19 পর্যন্ত ঢেউ
  if (t >= 10 && t < 20) return 600;
  return 80;
}

let depth = 0, done = 0, rejected = 0, maxDepth = 0;
for (let t = 0; t < 60; t++) {
  let incoming = arrivals(t);
  const room = MAX_DEPTH - depth;
  const accepted = Math.min(incoming, room);
  rejected += incoming - accepted;
  depth += accepted;
  const served = Math.min(depth, WORKER_RATE);
  depth -= served; done += served;
  maxDepth = Math.max(maxDepth, depth);
  if (t % 5 === 4 || t === 19) {
    const wait = (depth / WORKER_RATE).toFixed(1);
    console.log(`t=${String(t).padStart(2)}s in=${incoming} queue=${String(depth).padStart(4)} wait≈${wait}s done=${done} rejected=${rejected}`);
  }
}
console.log("max queue:", maxDepth, "total done:", done, "rejected:", rejected);

একই ঢেউ, ধাপে ধাপে। মানগুলো উপরের মডেলের আউটপুট থেকে নেওয়া।

1t=0–9 s: স্বাভাবিক, 80/s2t=10–14 s: সেল শুরু, 600/s3t=15–19 s: queue সীমায়, 4294t=20–24 s: ঢেউ শেষ, 80/s5t=25–34 s: worker জমা কাজ শেষ করছে6t=35–44 s: queue খালি

বাস্তবে আরও তিনটি জিনিস লাগে: queue-তে রাখার আগে stock-এর একটি দ্রুত আনুমানিক পরীক্ষা (আসল নিশ্চয়তা worker-এর transaction-এ); প্রতিটি অর্ডারে idempotency key, কারণ job একাধিকবার চলতে পারে; আর সেলের আগে load test, যাতে worker-এর আসল গতি মেপে সীমা ঠিক হয়। বড় মাপের waiting room আর টিকিট বিক্রির মতো চূড়ার নকশা System Design-এর টিকিট বুকিং case study-তে; queue-এর তত্ত্ব message queue পর্বে, rate limit-এর algorithm rate limiting পর্বে, আর ভিড় সামলানোর কৌশল overload পর্বে।

৮ · ধাপ ৫: ১০ লাখ জন — module, search, পুরোনো অর্ডার আর region

পাঁচ-ছয় বছরে বাজারঘর ১০ লাখ দৈনিক ব্যবহারকারী, আর দলে ২৫ জন প্রকৌশলী। মজার ব্যাপার, এই ধাপের বড় লক্ষণগুলোর অর্ধেক মেশিনের নয়, মানুষের। কল্পিত লক্ষণ: সপ্তাহে কয়েকবার deploy আটকে থাকে, কারণ এক দলের ভাঙা test আরেক দলের কাজ থামায়; খোঁজার পাতা ILIKE '%…%'-এ ধীর আর বাংলা বানানের ভুলে কিছুই পায় না; আর orders table-এ কয়েক কোটি সারি, যার বেশিরভাগ বছর পুরোনো, কিন্তু প্রতিটি index আর backup-এ সেগুলোর ভার।

Modular monolith আগে, service শুধু যেখানে লাভ

বাজারঘরের দল প্রথমে কোড ভাঙেনি, সীমা কড়া করেছে। একটি modular monolith-এ প্রতিটি module নিজের ডেটার মালিক; অন্য module শুধু তার প্রকাশ্য function ডাকে, তার table-এ সরাসরি query নয়। কোন module আলাদা service হবে, তার জন্য তিনটি প্রশ্ন: ভারের ধরন কি খুব আলাদা? আলাদা গতিতে deploy করতে চায় এমন আলাদা দল আছে কি? Network আর দুই জায়গার ডেটার দাম কি লাভের চেয়ে কম? Notification তিনটিতেই হ্যাঁ (ঈদে লাখো বার্তা, নিজস্ব retry, প্রায় স্বাধীন); checkout তিনটিতেই না। Stack আর architecture বাছাইয়ের বড় প্রশ্নগুলো পর্ব ৮৫-এ (Stack বাছাই), আর তত্ত্ব System Design-এর microservices পর্বে।

Search: আলাদা ব্যবস্থা, কিন্তু আগে PostgreSQL-এর সীমা দেখা

ILIKE '%ইলিশ%' সাধারণ B-tree index ব্যবহার করতে পারে না, তাই বড় table-এ পুরোটা পড়ে। প্রথম ধাপ PostgreSQL-এর নিজের full-text search বা pg_trgm extension-এর trigram index; অনেক দোকানের জন্য এটুকুই যথেষ্ট। বানান-ভুল সহ্য করা, প্রাসঙ্গিকতা ধরে সাজানো আর দ্রুত facet দরকার হলে দলগুলো প্রায়ই আলাদা search engine নেয়, যেমন OpenSearch, Meilisearch বা Typesense (উদাহরণ মাত্র; বাংলা সমর্থন নিজে পরীক্ষা করে দেখুন)। দাম: পণ্য বদলালে index-এ পাঠানোর পথ (queue বা outbox), আর index একটু পিছিয়ে থাকে। সত্যের উৎস PostgreSQL-ই থাকে। তত্ত্ব System Design-এর search পর্বে।

পুরোনো অর্ডার: partition আর archive

ক্যালকুলেটর বলছে ১০ লাখে বছরে প্রায় দেড় কোটি অর্ডার। PostgreSQL ১০ (২০১৭) থেকে declarative partitioning আছে: orders একটি “মা” table, আর প্রতিটি মাসের অর্ডার নিজের partition-এ। WHERE created_at >= … থাকলে PostgreSQL শুধু দরকারি partition পড়ে, আর পুরোনো মাস পুরো partition হিসেবে detach করে archive-এ পাঠানো যায়, এক এক সারি মোছার বদলে। দুই বছরের পুরোনো অর্ডার যায় সস্তা storage-এ; কত দিন রাখতে হবে, সেটি হিসাব আর আইনের প্রশ্ন। দাম: customer ধরে খোঁজায় partition key (তারিখ) না থাকলে সব partition পড়তে হয়। এটি এক database-এর ভেতরের ভাগ; কয়েকটি database-এ ভাগ (sharding) অনেক বেশি কঠিন, আর বাজারঘর তা করেনি। পার্থক্য System Design-এর partitioning পর্বে।

Region: একটি সতর্ক নোট

বাজারঘরের প্রায় সব ক্রেতা বাংলাদেশে। তাই multi-region মানে এখানে প্রথমে কাছের একটি region-এ মূল server আর CDN দিয়ে static অংশ কাছে আনা। দ্বিতীয় region-এ শুধু backup আর একটি replica, যাতে পুরো data center গেলে দোকান ফেরানো যায়; কত ঘণ্টায় আর কত মিনিটের ডেটা হারিয়ে, তা আগে লিখে মহড়া দেওয়া। দুই region-এ একসাথে লেখা conflict আর খরচে খুব কঠিন, আর এক দেশের দোকানে সাধারণত লাগে না। নিজের ক্রেতাদের latency মেপে নিশ্চিত হন; আর System Design-এর disaster recovery পর্ব দেখুন।

৯ · সাধারণ ভুল আর যা ইচ্ছে করে করা হয়নি

পাঁচ ধাপ পেরিয়ে চারটি ভুল বারবার দেখা যায়। প্রতিটির পাশে বাজারঘরের গল্পের প্রমাণ।

আর প্রতিটি ধাপে যা পিছিয়ে রাখা হয়েছিল, এক জায়গায়। লক্ষ করুন, প্রতিটির পাশে সেই লক্ষণ, যেটি এলে তবেই করা হবে।

১০ · AI-এর যুগে scaling-এর সিদ্ধান্ত

শুধু “১০ লাখ ব্যবহারকারীর জন্য কীভাবে scale করব” জিজ্ঞেস করলে AI প্রায়ই একটি সুন্দর কিন্তু সাধারণ ছবি আঁকে: Kubernetes, microservice, Kafka, sharded database, multi-region. ছবিটি বড় কোম্পানির blog থেকে শেখা, আপনার graph থেকে নয়। AI আপনার query plan, আপনার peak factor বা আপনার দলের আকার জানে না। তাই তার কাছে মাপ নিয়ে যান, আর তার প্রতিটি পরামর্শকে একটি পরীক্ষাযোগ্য অনুমান হিসেবে নিন।

AI-এর scaling পরামর্শ যাচাইয়ের চেকলিস্ট

• পরামর্শটি আমার মাপা লক্ষণের সাথে মেলে (কোন graph, কোন route, কোন query), শুধু “বড় সাইট এভাবে করে” নয়
• পরিবর্তনের আগে আর পরে একই load test চালিয়েছি, একাধিকবার, আর “একটি local run” বলে লিখে রেখেছি
• প্রতিটি config আর API (pool-এর option, Redis adapter, partition-এর syntax) আমার version-এর docs-এ মিলিয়েছি; AI প্রায়ই পুরোনো বা বানানো option দেয়
• নতুন অংশের ব্যর্থতায় কী হবে ভেবেছি: Redis, replica, queue থামলে দোকান কী করবে
• কোডের diff পড়েছি: authorization বাদ পড়েনি, cache-এ এক ক্রেতার ডেটা আরেকজনের কাছে যাচ্ছে না, error চেপে রাখা হয়নি
• AI-কে কোনো password, connection string, ক্রেতার তথ্য বা production-এর log-এর ব্যক্তিগত অংশ দিইনি