Case study: ticket booking আর payment — concurrency, idempotency আর ledger

১ · সমস্যা আর পরিধি — একটি টিকিট প্ল্যাটফর্মের requirement

ঈদের আগে বাসের টিকিটের ভিড় যিনি দেখেছেন, তিনি সমস্যাটা জানেন: কাউন্টার খোলার আগেই লম্বা লাইন, সবাই একই দিনের একই রুটের টিকিট চান, আর সিট সীমিত। এবার কাউন্টারটি অনলাইনে নিন। এই পর্বের বিষয় “সিটঘর” — একটি টিকিট প্ল্যাটফর্ম (কাল্পনিক): আন্তঃজেলা বাসের সিট আর কনসার্ট বা খেলার টিকিট বিক্রি হয়, ক্রেতা নিজে সিট বাছেন, আর টাকা দেন বাইরের payment gateway বা mobile financial service (MFS) দিয়ে। কোনো বাস্তব রেল, বাস বা টিকিট-সেবার নকশা এখানে বর্ণনা করা হয়নি; সব সংখ্যা “ধরা যাক”।

এগোব পর্ব ০৬-এর আট ধাপের কাঠামো ধরে: পরিধি, হিসাব, API ও data model, ছবি, তারপর চারটি গভীর অংশ, ভাঙন আর সারাংশ। আগের মডিউলে শেখা প্রতিটি কৌশল এখানে এক বাক্যে প্রয়োগ হবে, সাথে তার পর্বের link.

ইন্টারভিউয়ার যে প্রশ্নগুলো শুনতে চান

• সিট বাছাই, না শুধু সংখ্যা? নির্দিষ্ট সিট মানে প্রতিটি সিট একটি সারি; গ্যালারি মানে একটি counter (অংশ ৫)।
• ভিড় কখন? বিক্রির সময় জানা থাকলে আগে থেকে সার্ভার বাড়ানো, cache গরম করা আর load test সম্ভব।
• Hold কতক্ষণ, এক account কতগুলো? ব্যবসার সিদ্ধান্ত, কিন্তু হিসাব বদলায় (অংশ ২)।
• টাকা কোন পথে, আর ফেরতের নীতি কী? Gateway কি idempotency key, webhook আর দিনশেষের রিপোর্ট দেয়; বাতিলে মাশুল কত — ledger-এর entry এখান থেকে আসে।

শুরুতেই একটি সিদ্ধান্ত পুরো নকশা গড়ে দেয়: সিস্টেমটি আসলে দুই জগৎ। দেখার জগৎ — ট্রিপের তালিকা, seat map, দাম — পড়া হয় বিপুল পরিমাণে, আর এক-দুই সেকেন্ড পুরোনো তথ্যেও ক্ষতি নেই। কেনার জগৎ — hold, অর্ডার, টাকা — অনুরোধ অনেক কম, কিন্তু প্রতিটি সিট আর প্রতিটি টাকার জন্য একটিই সত্য চাই।

২ · হিসাব — on-sale-এর চূড়া, waiting room-এর হার আর hold-এর মেয়াদ

নকশা ঠিক হয় বিক্রি শুরুর প্রথম কয়েক মিনিটে, গড় দিনে নয় (পর্ব ০৩-এর peak-এর নিয়ম)। ধরা যাক ঈদের আগের এক সকালে ৮টায় এক দিনের সব ট্রিপের বিক্রি খোলে:

Hold-এর মেয়াদ কী করে, বুঝতে Little-এর সূত্র লাগবে (পর্ব ০৪): যে সিটগুলো কেউ ধরে রেখে চলে যান, সেগুলো মেয়াদ শেষ না হওয়া পর্যন্ত আটকে থাকে। আটকে থাকা সংখ্যা = আটকানোর হার × আটকে থাকার সময়, যতক্ষণ না পুরো inventory ফুরায়। নিচের calculator প্রতিটি সংখ্যা নিজে গোনে:

// On-sale estimator for a fictional ticket platform. Every input is an assumption.
const S = 120000;          // seats on sale (3,000 trips x 40 seats)
const U = 600000;          // hopeful buyers in the first 10 minutes
const firstMin = 0.5;      // share of U that arrives in the first 60 s
const A = 400;             // waiting room admits this many users per second
const p = 0.7, k = 1.8;    // share of admitted users who pay; seats per order
const writesPayer = 9, writesLeaver = 1, holdTries = 1.3;   // DB writes per user
const fmt = (x) => Math.round(x).toLocaleString("en-US");

const active = U * firstMin;
console.log("peak arrivals        :", fmt(active / 60), "users/s");
console.log("no waiting room      :", fmt(active / 2), "req/s to the booking API (1 req per 2 s)");
console.log("waiting room polls   :", fmt(U / 20), "req/s at the edge (1 poll per 20 s)");
console.log("admitted in the flow :", fmt(A * 180), "users -> API", fmt(A * 180 * 0.1), "req/s");
const writes = A * (holdTries + p * writesPayer + (1 - p) * writesLeaver);
console.log("DB write QPS         :", fmt(writes), "writes/s");
const sold = A * p * k, ghostRate = A * (1 - p) * k;      // seats per second
console.log("seats held per second:", fmt(sold), "by payers +", fmt(ghostRate), "by leavers");
console.log("users needed to sell out:", fmt(S / (p * k)), "of", fmt(U));
const tFull = S / (sold + ghostRate);
console.log("\nTTL   ghost seats  share  first 'sold out' at  ghosts return from");
for (const ttlMin of [1, 2, 5, 10]) {
  const T = ttlMin * 60;
  const ghost = T >= tFull ? ghostRate * tFull : ghostRate * T;
  const tOut = T >= tFull ? tFull : (S - ghostRate * T) / sold;
  console.log(String(ttlMin).padStart(2) + " min" + fmt(ghost).padStart(12) +
    ((100 * ghost / S).toFixed(1) + "%").padStart(8) +
    (tOut.toFixed(1) + " s").padStart(19) + (T + " s").padStart(18));
}

peak arrivals        : 5,000 users/s
no waiting room      : 150,000 req/s to the booking API (1 req per 2 s)
waiting room polls   : 30,000 req/s at the edge (1 poll per 20 s)
admitted in the flow : 72,000 users -> API 7,200 req/s
DB write QPS         : 3,160 writes/s
seats held per second: 504 by payers + 216 by leavers
users needed to sell out: 95,238 of 600,000

TTL   ghost seats  share  first 'sold out' at  ghosts return from
 1 min      12,960   10.8%            212.4 s              60 s
 2 min      25,920   21.6%            186.7 s             120 s
 5 min      36,000   30.0%            166.7 s             300 s
10 min      36,000   30.0%            166.7 s             600 s

Storage চাপ নয়: ধরা যাক বছরে ২ কোটি অর্ডার, অর্ডার-payment-ledger-outbox মিলিয়ে প্রতিটি প্রায় ২ KB — বছরে প্রায় ৪০ GB, পাঁচ বছরে প্রায় ২০০ GB. সমস্যাটা আকারের নয়, কয়েক মিনিটের ঢেউয়ের। আর ৫০,০০০ আসনের একটি স্টেডিয়ামের seat map-ও ছোট: প্রতি আসনে ২ bit (খালি, hold, বিক্রি) ধরলে প্রায় ১২,৫০০ byte — cache আর CDN-এ সহজে আঁটে।

৩ · API আর data model — প্রতিটি লেখায় key, প্রতিটি সিটে একটি সারি

API ছোট রাখুন, আর প্রতিটি লেখার অনুরোধে idempotency key বাধ্যতামূলক করুন — নিয়মটি পর্ব ০৮-এর নিরাপদ retry-র; দুর্বল মোবাইল নেটওয়ার্কে retry এখানে নিয়ম, ব্যতিক্রম নয়।

POST /v1/holds
Authorization: Bearer <session>
Queue-Token: qt_8f2a...
Idempotency-Key: 5d1c7e02
{"show_id": 7, "seats": ["A1", "A2"]}

201 Created
{"hold_id": "h1", "expires_at": "08:12:30", "amount_paisa": 170000}

409 Conflict
{"error": "seat_unavailable", "seats": ["A2"], "seatmap_version": 813}

টাকা লেখা হয় পয়সায়, পূর্ণসংখ্যা হিসেবে — minor unit; floating-point-এ ০.১ + ০.২ ঠিক ০.৩ হয় না, আর লাখো লেনদেনে সেই ভুল জমে। 409-এর উত্তরে নতুন seat map-এর version থাকে, যাতে app সাথে সাথে map বদলাতে পারে।

Data model — কোন ডেটা কোথায়, কোন key-তে ভাগ

সিট, অর্ডার আর টাকা relational ডেটাবেসে (PostgreSQL বা MySQL-এর মতো) — দরকার শর্তসহ লেখা, CHECK, UNIQUE আর ACID transaction (পর্ব ২০)। ভাগের key — partition key — show_id: একটি show-এর সব সিট, hold আর অর্ডার এক shard-এ, তাই confirm-এর পুরো কাজ এক local transaction (পর্ব ২৩)। “আমার টিকিট” তালিকা user_id দিয়ে খোঁজা হয় — তার জন্য আলাদা read model, event থেকে বানানো (পর্ব ৩৫-এর CQRS); ট্রিপ খোঁজা search index-এ (পর্ব ২৭), আর e-ticket-এর PDF থাকে object storage-এ (পর্ব ২৬)।

৪ · High-level design — দরজা থেকে খাতা পর্যন্ত

পুরো ছবি নিচে। ওপর থেকে নিচে একটি অনুরোধের পথ; ডানে বাইরের gateway; নিচে খবর পাঠানোর পথ।

পড়ার পথ: app → CDN (স্থির আসনবিন্যাস) → booking API → seat-map cache; miss হলে replica থেকে, একসাথে আসা miss মিলিয়ে একটিতে (request coalescing, পর্ব ২৯)। লেখার পথ: booking service-এর শর্তসহ লেখা seat DB-র primary-তে → payment service → gateway; খবর ফেরে webhook-এ, নিশ্চিতকরণ যায় outbox → relay → broker → notification service হয়ে।

এবার রুমানার একটি কেনা, শুরু থেকে শেষ — সব ঠিকঠাক চললে:

৫ · Deep dive ১ — inventory আর concurrency: একটি সিট, একজন মালিক

প্রতিটি সিটের জীবন একটি ছোট state machine. অবস্থা তিনটি, আর প্রতিটি বদল একটি শর্তসহ লেখা:

বিপদ একটিই: দুজন একই মুহূর্তে একই খালি সিট দেখেন, আর দুজনেই লেখেন — overselling বা double booking. পর্ব ২৪-এর অ্যাপ-স্তরের প্যাটার্ন থেকে তিনটি পথ এখানে প্রয়োগ হয়:

কোনটি কত ভালো, একটি simulator দেখায়। ১০০টি সিট, ৩০০ জন ক্রেতা প্রথম ২০০ ms-এর মধ্যে আসেন; প্রত্যেকে seat map দেখে একটি খালি সিট বাছেন, তারপর ৫–৩০ ms পরে লেখেন। লেখা ব্যর্থ হলে আবার দেখে অন্য সিট, সর্বোচ্চ তিনবার। প্রতিটি কৌশলে আগমন আর দেরি একই seeded সংখ্যায়:

// Double booking race: 300 buyers, 100 seats, the same seeded arrivals for every strategy.
function mulberry32(a) {
  return () => { a |= 0; a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const SEATS = 100, BUYERS = 300, MAX_TRIES = 3;
function run(mode) {
  const r = mulberry32(42), owners = Array.from({ length: SEATS }, () => []);
  const ver = new Array(SEATS).fill(0); let showVer = 0, fails = 0, retries = 0, gaveUp = 0;
  const ev = [];                                  // arrivals spread over the first 200 ms
  for (let b = 0; b < BUYERS; b++) ev.push({ t: Math.floor(r() * 200), b, kind: "read", tries: 1 });
  while (ev.length) {
    ev.sort((x, y) => x.t - y.t || x.b - y.b); const e = ev.shift();
    if (e.kind === "read") {                      // look at the seat map, pick a free seat
      const free = owners.map((o, s) => o.length ? -1 : s).filter((s) => s >= 0);
      if (!free.length) continue;                 // sold out: the buyer leaves
      const s = free[Math.floor(r() * free.length)];
      const v = mode === "version per show" ? showVer : ver[s];
      ev.push({ ...e, kind: "write", t: e.t + 5 + Math.floor(r() * 25), s, v });
      continue;
    }
    const ok = mode === "naive read-then-write" ? true
      : mode === "conditional UPDATE" ? owners[e.s].length === 0
      : mode === "version per seat" ? ver[e.s] === e.v : showVer === e.v;
    if (ok) { owners[e.s].push(e.b); ver[e.s]++; showVer++; continue; }
    fails++;                                      // 0 rows updated: re-read and try again
    if (e.tries < MAX_TRIES) { retries++; ev.push({ ...e, kind: "read", t: e.t + 1, tries: e.tries + 1 }); }
    else gaveUp++;
  }
  const tickets = owners.reduce((n, o) => n + o.length, 0), sold = owners.filter((o) => o.length).length;
  console.log(mode.padEnd(22) + String(tickets).padStart(8) + String(tickets - sold).padStart(10) +
    String(fails).padStart(8) + String(retries).padStart(9) + String(gaveUp).padStart(9) + String(SEATS - sold).padStart(8));
}
console.log("strategy               tickets  oversold   fails  retries  gave up  unsold");
for (const m of ["naive read-then-write", "conditional UPDATE", "version per seat", "version per show"]) run(m);

strategy               tickets  oversold   fails  retries  gave up  unsold
naive read-then-write      193        93       0        0        0       0
conditional UPDATE         100         0     109      100        9       0
version per seat           100         0     109      100        9       0
version per show            32         0     838      570      268      68

কয়েকটি সিট একসাথে, আর মেয়াদ

রুমানা A1 আর A2 একসাথে চান; একটি পেলে চলবে না — পুরো শর্ত একটি বাক্যে, অথবা এক transaction-এ দুটি লেখা আর বদলানো সারি ২ না হলে rollback. Pessimistic পথে সিটগুলো সবসময় একই ক্রমে lock করুন, নইলে deadlock (DBMS কোর্সের deadlock পর্ব)।

মেয়াদ শেষে সিট কে ফেরত দেবে? শর্তেই মেয়াদ রাখুন: “খালি” মানে available, অথবা held কিন্তু held_until পেরিয়ে গেছে — Redis-এর lazy expiration-এর মতো। একটি sweeper job (পর্ব ৩৭-এর delayed job) পরিষ্কার করে আর cache ও waiting room-কে খবর দেয়, কিন্তু সঠিকতা তার ওপর নির্ভর করে না। নিচের লাইভ SQL-এ সময় মিনিটে (৬০০ = সকাল ১০টা); নমুনা ডেটাবেসে show ৭-এর A1–A4 খালি, আর আসনহীন show ৯-এ ৩টি টিকিট বাকি:

-- Time is minutes since midnight: 600 = 10:00. A hold lasts 10 minutes.
-- 10:00 Rumana holds A1 and A2. A seat is free if available OR its hold expired.
UPDATE seats SET status = 'held', hold_id = 'h1', held_until = 610
WHERE show_id = 7 AND seat IN ('A1', 'A2')
  AND (status = 'available' OR (status = 'held' AND held_until < 600));
-- 10:03 Karim asks for A2 and A3 together: all or nothing, so 0 rows.
UPDATE seats SET status = 'held', hold_id = 'h2', held_until = 613
WHERE show_id = 7 AND seat IN ('A2', 'A3')
  AND (SELECT COUNT(*) FROM seats WHERE show_id = 7 AND seat IN ('A2', 'A3')
       AND (status = 'available' OR (status = 'held' AND held_until < 603))) = 2;
-- 10:03 Karim takes A3 and A4 instead.
UPDATE seats SET status = 'held', hold_id = 'h2', held_until = 613
WHERE show_id = 7 AND seat IN ('A3', 'A4') AND status = 'available';
-- 10:08 Rumana's payment succeeds: confirm only her own, unexpired hold.
UPDATE seats SET status = 'booked' WHERE hold_id = 'h1' AND status = 'held' AND held_until >= 608;
-- 10:15 Karim's payment arrives after his hold expired: 0 rows, so refund him.
UPDATE seats SET status = 'booked' WHERE hold_id = 'h2' AND status = 'held' AND held_until >= 615;
-- 10:16 Sumi takes A4: the expired hold is reclaimed by the same WHERE.
UPDATE seats SET status = 'held', hold_id = 'h3', held_until = 626
WHERE show_id = 7 AND seat = 'A4'
  AND (status = 'available' OR (status = 'held' AND held_until < 616));
SELECT seat, status, hold_id, held_until FROM seats WHERE show_id = 7 ORDER BY seat;
-- General admission: a counter, decremented atomically with a guard.
UPDATE ga_stock SET remaining = remaining - 2 WHERE show_id = 9 AND remaining >= 2;
UPDATE ga_stock SET remaining = remaining - 2 WHERE show_id = 9 AND remaining >= 2;
SELECT show_id, remaining FROM ga_stock;

Hot row, hot shard আর ভাগের কৌশল

প্রতিটি সিট আলাদা সারি বলে সংঘাত ছড়িয়ে যায়, শুধু জনপ্রিয় সিটে ভিড় জমে। কিন্তু general admission বা আসনহীন টিকিটে সবাই একটিই counter সারি কমান। পর্ব ২৪-এর ব্যস্ত সারির হিসাব: প্রতিটি লেখা lock ধরে h সেকেন্ড, তাই সারিটিতে সর্বোচ্চ ১ ÷ h লেখা প্রতি সেকেন্ডে। h = ৪ ms হলে ২৫০; প্রথম মিনিটে সেকেন্ডে ৩,০০০ টিকিটের চাহিদা থাকলে অন্তত ১২টি ভাগ লাগে। কৌশলগুলো:

• Counter ভাগ করা: একটি গ্যালারির ১০,০০০ টিকিট ১২টি bucket-এ, প্রতিটি অনুরোধ একটি bucket থেকে কমায়, খালি হলে পাশেরটিতে — sharded counter; মোট সীমা কখনো ভাঙে না, কারণ প্রতিটি bucket-এর নিজের CHECK >= 0. এটি Patrick O’Neil-এর ১৯৮৬ সালের escrow পদ্ধতির ধারণা, পর্ব ৪৬-এর bounded counter-এর আত্মীয়।
• একজন লেখক: একটি গ্যালারি বা সেকশনের সব অনুরোধ একটি queue-তে, একটি worker ক্রমানুসারে সিদ্ধান্ত নেয় আর এক transaction-এ কয়েকশো hold লেখে — single-writer নীতি (পর্ব ৪৩-এর lock ছাড়াই)।

Partition key show_id হাজারো ট্রিপকে হাজারো shard-এ ছড়ায়, কিন্তু ৫০,০০০ আসনের একটি কনসার্ট পুরোটাই এক shard-এ — একটি hot spot, যার আলোচনা পর্ব ২৩-এর hot spot আর skew অংশে। প্রতিকার: এমন show আলাদা শক্তিশালী shard বা cell-এ, আর অর্ডার এক সেকশনে সীমিত করে key (show_id, section) (ভাবনার প্রশ্ন ১)।

৬ · Deep dive ২ — on-sale-এর ঢেউ: waiting room, bot আর seat map

দরজা না থাকলে সেকেন্ডে দেড় লাখ অনুরোধ, থাকলে ভেতরে হাজার সাতেক (অংশ ২)। Virtual waiting room আসলে edge-এ বসানো admission control — পর্ব ১৮-এর দরজায় গোনা, মানুষের জন্য সাজানো। ফেরিঘাটের সিরিয়ালের মতো: সবাই একসাথে উঠতে চাইলে কেউ ওঠেন না; টোকেন নিয়ে অপেক্ষা করলে ফেরি ভরা থাকে, ঘাটে ধাক্কাধাক্কি নেই।

যন্ত্রটি কীভাবে চলে

1. স্থির পাতা, edge থেকে: সারির পাতা আর খোঁজের উত্তর CDN থেকে (পর্ব ১৭); origin-এ ভার নেই।
2. খোলার আগে এলে lottery, পরে এলে সারি: নির্দিষ্ট সময়ের আগে আসা সবার নম্বর খোলার মুহূর্তে এলোমেলো; পরে আসা মানুষ আসার ক্রমে পেছনে — মিলিসেকেন্ডের দৌড় সুবিধা পায় না।
3. স্বাক্ষর-করা token: নম্বর, session আর মেয়াদ একটি token-এ, server-এর গোপন key দিয়ে HMAC-স্বাক্ষর (পর্ব ১৫)। ডেটাবেস ছাড়াই যাচাই; session-এ বাঁধা, তাই বদলানো বা বেচা যায় না।
4. ভর্তির নম্বর X এগোয় সেকেন্ডে A করে: নম্বর ≤ X হলে ১৫ মিনিটের admitted token. A ঠিক করে একটি controller, ডেটাবেসের p99 আর error দেখে — পর্ব ৪৯-এর adaptive সীমা.
5. সিট ফুরালে থামা: ভর্তি বন্ধ, অপেক্ষারতদের সৎ খবর; hold ফিরলে আবার খোলে।

Bot আর অপব্যবহার — শুধু সুরক্ষার দিক থেকে

জনপ্রিয় টিকিটে script দিয়ে গণ-কেনা আর পরে বেশি দামে বিক্রির চেষ্টা থাকেই। Bot mitigation একটি যন্ত্র নয়, কয়েকটি স্তর:

Seat map-এর cache — পুরোনো, কিন্তু নিরাপদ

প্রতিটি hold-এর আগে seat map কয়েকবার দেখা হয়। Map আসে cache-aside পথে (পর্ব ২৮), এক-দুই সেকেন্ডের TTL বা বদলের event-এ নতুন version; একসাথে হাজার miss হলে coalescing (পর্ব ২৯-এর stampede-রোধ)। স্থির আসনবিন্যাস CDN-এ দীর্ঘ মেয়াদে, শুধু ছোট availability-অংশ ঘনঘন বদলায়।

ভিড় সামলাতে পর্ব ১৮-এর graceful degradation-ও কাজে লাগে: on-sale-এর সময় সুপারিশ, রিভিউ আর বিশদ খোঁজ বন্ধ রেখে সব সামর্থ্য কেনার পথে দেওয়া।

৭ · Deep dive ৩ — payment: idempotency, অজানা ফল আর reconciliation

সিট আমাদের ডেটাবেসে, টাকা অন্যের সিস্টেমে; মাঝে কোনো যৌথ transaction নেই, আর MFS-এ PIN দেওয়ার মাঝপথে সংযোগও যেতে পারে। নকশা তিনটি নিয়মে দাঁড়ায়।

নিয়ম ১ — প্রতিটি কড়ায় একটি key

Gateway key না নিলে? তাহলে retry-র আগে অবস্থা জিজ্ঞেস করুন (“অর্ডার O1-এর চার্জ হয়েছে?”), আর নিজের দিকে “পাঠানো হচ্ছে” লিখে রাখুন — পর্ব ৩৪-এর নিয়ন্ত্রণের বাইরের side effect. টাকার পথে key ছাড়া অন্ধ retry চলে না।

নিয়ম ২ — Timeout মানে UNKNOWN, FAILED নয়

Payment-এর অবস্থা একটি state machine; প্রতিটি বদল একটি শর্তসহ UPDATE, যেমন SET state = 'SUCCEEDED' WHERE id = 'P1' AND state IN ('PENDING', 'UNKNOWN') — দেরিতে আসা দ্বিতীয় webhook ০ সারি পায়, অবস্থা পেছনে যায় না।

UNKNOWN চলাকালীন সিটের কী হবে? Payment শুরু হলে hold-এর মেয়াদ একবার, একটি সীমা পর্যন্ত বাড়ে (ধরা যাক ৫ মিনিট); তারপরও অজানা থাকলে সিট ছাড়া, আর পরে সফলতার খবর এলে টাকা ফেরত — নিচের stepper. বিকল্প নীতি: সিট তখনো খালি থাকলে আবার hold করে confirm. এখানে payment-ই pivot: confirm একটি local, শর্তসহ, retry-যোগ্য লেখা — যতক্ষণ hold বৈধ। Saga-র তত্ত্ব পর্ব ২৫-এর saga অংশে।

এবার বড় পরিসরে: ২,০০০টি payment, স্বাভাবিক সময়ে ৩% অনুরোধে timeout, আর অর্ডার ১০০১–১২০০-এর সময় gateway ধীর, ৫০% timeout. Timeout-এর ৬০% ক্ষেত্রে টাকা আসলে কেটেছে, শুধু উত্তর হারিয়েছে; ২% ক্রেতা দুবার চাপেন; উত্তর না এলে সর্বোচ্চ তিনবার চেষ্টা। দুই নকশা — key ছাড়া (timeout মানে ব্যর্থ) আর key-সহ (timeout মানে UNKNOWN) — একই seeded দুর্ঘটনায়, তারপর gateway-এর রিপোর্টের সাথে মিলিয়ে:

// 2,000 payments through a gateway with seeded timeouts, a slow period and double taps.
function mulberry32(a) {
  return () => { a |= 0; a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const N = 2000, TRIES = 3, DOUBLE_TAP = 0.02, APPLIED_IF_TIMEOUT = 0.6;
const timeoutP = (id) => (id > 1000 && id <= 1200 ? 0.5 : 0.03);  // orders 1001-1200: gateway is slow
const W = [8, 7, 9, 8, 9, 8, 5, 6];
const show = (m, row) => console.log(m.padEnd(11) + row.map((v, i) => String(v).padStart(W[i])).join(""));
function run(useKey) {
  const r = mulberry32(7), charges = new Map(), ours = new Map();
  for (let id = 1; id <= N; id++) {
    let paid = false;
    const calls = r() < DOUBLE_TAP ? 2 : 1;       // a double tap sends a second, parallel request
    for (let c = 0; c < calls; c++)
      for (let t = 1; t <= TRIES; t++) {          // retry only while the reply is missing
        const timeout = r() < timeoutP(id), applied = !timeout || r() < APPLIED_IF_TIMEOUT;
        if (applied && !(useKey && charges.has(id))) charges.set(id, (charges.get(id) || 0) + 1);
        if (!timeout) { paid = true; break; }     // with a key, the reply carries the first result
      }
    ours.set(id, paid ? "PAID" : useKey ? "UNKNOWN" : "FAILED");   // no key: timeout = failure
  }
  const c = { total: 0, double: 0, chgFail: 0, unknown: 0, bad: 0, refunds: 0, late: 0, ok: 0 };
  for (const [id, st] of ours) {                  // reconciliation with the gateway's report
    const n = charges.get(id) || 0; c.total += n;
    if ((st === "PAID") !== (n === 1)) c.bad++;   // mismatch before reconciliation
    if (n > 1) c.double++; if (st === "FAILED" && n > 0) c.chgFail++;
    if (st === "UNKNOWN") { c.unknown++; ours.set(id, n > 0 ? "PAID" : "FAILED"); if (n > 0) c.late++; }
    const keep = ours.get(id) === "PAID" ? 1 : 0;  // keep one charge for a paid order, refund the rest
    c.refunds += n - Math.min(n, keep); if (Math.min(n, keep) === keep) c.ok++;
  }
  show(useKey ? "with key" : "without key", Object.values(c));
}
show("mode", ["charges", "double", "chg+fail", "unknown", "mismatch", "refunds", "late", "ok"]);
run(false); run(true);

mode        charges double chg+fail unknown mismatch refunds late    ok
without key    2181    164       17       0      157     199    0  2000
with key       1999      0        0      18       17       0   17  2000

নিয়ম ৩ — দিনশেষে মিলিয়ে দেখা

Webhook হারায়, bug থাকে, gateway-ও ভুল করে। তাই প্রতিদিন (ভিড়ের দিনে ঘণ্টায় ঘণ্টায়) gateway-এর settlement report নিজের payment আর ledger-এর সাথে মেলানো — reconciliation, মুদি দোকানের খাতা আর ক্যাশবাক্স মেলানোর মতো:

আর নিশ্চিতকরণের খবর কখনো transaction-এর ভেতরে SMS পাঠিয়ে নয়: সিট booked, অর্ডার CONFIRMED আর outbox-এর BookingConfirmed একসাথে commit, তারপর relay পাঠায় — পর্ব ২৫-এর outbox. SMS, push আর email-এর নির্ভরযোগ্য পথ, retry আর duplicate-রোধ পর্ব ৫৭-এর notification system-এ।

৮ · Deep dive ৪ — ledger: প্রতিটি টাকার দুই দিক

“গতকাল কত টাকা এল, কার কাছে কত পাওনা, কত ফেরত গেল?” — এই প্রশ্নের উত্তর একটি balance কলাম দিতে পারে না, কারণ কলামটি শুধু শেষ অবস্থা জানে। মুদি দোকানি খাতায় প্রতিটি বাকি আর শোধ আলাদা লাইনে লেখেন, কখনো কেটে মোছেন না; মাসশেষের হিসাব লাইনগুলো যোগ করে। Ledger ঠিক তাই, আর double-entry তাতে একটি কঠোর নিয়ম যোগ করে: প্রতিটি লেনদেন অন্তত দুটি হিসাবে লেখা হয়, একদিকে debit, অন্যদিকে সমান credit — লাইনগুলোর যোগফল শূন্য। ধারণাটির event sourcing-এর সাথে সম্পর্ক পর্ব ৩৫-এর ledger অংশে; এখানে প্রয়োগ।

নিয়মগুলো: এক, প্রতিটি লেনদেনের লাইনের যোগফল শূন্য, নইলে লেখাই হয় না। দুই, entry শুধু যোগ হয় — append-only; ভুল শোধরায় উল্টো entry — পূর্ণ audit trail. তিন, balance গোনা হয় লাইন যোগ করে; আলাদা balance সারি রাখলে তা একই transaction-এ। চার, লেনদেনের id UNIQUE — retry-তে দ্বিতীয়বার লেখা আটকায়। পাঁচ, টাকা পয়সায়, পূর্ণসংখ্যায়, আর কমিশনের ভাগে গোলাকারের লেখা নিয়ম। নিচের ledger একটি booking, তার fee, একটি দ্বিতীয় booking (retry-সহ), প্রথমটির refund আর একটি ভুল payout লেখার চেষ্টা করে:

// Double-entry ledger: append-only lines in paisa (integers), every transaction sums to zero.
const ledger = [], posted = new Set();
const tk = (taka) => Math.round(taka * 100);             // money as integer paisa, never floats
function post(txn, lines) {
  const sum = lines.reduce((s, [, amt]) => s + amt, 0);
  if (posted.has(txn)) return console.log(txn.padEnd(13) + "duplicate txn id, ignored");
  if (sum !== 0) return console.log(txn.padEnd(13) + "REJECTED: lines sum to " + sum + " paisa");
  posted.add(txn);
  lines.forEach(([acct, amt], i) => ledger.push(Object.freeze({ txn, line: i + 1, acct, amt })));
  console.log(txn.padEnd(13) + "posted " + lines.length + " lines");
}
// Debit = +, credit = -. Booking of 1,700 Tk; the platform keeps a 10% commission.
post("T1 book O1", [["gateway_clearing", tk(1700)], ["operator_payable", -tk(1530)], ["platform_revenue", -tk(170)]]);
post("T2 fee O1", [["gateway_fees", tk(30)], ["gateway_clearing", -tk(30)]]);
post("T3 book O2", [["gateway_clearing", tk(850)], ["operator_payable", -tk(765)], ["platform_revenue", -tk(85)]]);
post("T3 book O2", [["gateway_clearing", tk(850)], ["operator_payable", -tk(765)], ["platform_revenue", -tk(85)]]);
post("T4 refund O1", [["operator_payable", tk(1530)], ["platform_revenue", tk(170)], ["gateway_clearing", -tk(1700)]]);
post("T5 payout", [["operator_payable", tk(765)], ["bank", -tk(750)]]);       // a typo: 750 instead of 765
function report(title) {
  const bal = {}, byTxn = {};                              // balances are derived, never stored alone
  for (const e of ledger) { bal[e.acct] = (bal[e.acct] || 0) + e.amt; byTxn[e.txn] = (byTxn[e.txn] || 0) + e.amt; }
  console.log("\n" + title);
  for (const [a, v] of Object.entries(bal)) console.log("  " + a.padEnd(18) + (v / 100).toFixed(2).padStart(10) + " Tk");
  console.log("  sum of all lines  " + String(Object.values(bal).reduce((s, v) => s + v, 0)).padStart(10) + " paisa");
  const bad = Object.entries(byTxn).filter(([, s]) => s !== 0);
  console.log("  unbalanced txns: " + (bad.length ? bad.map(([t, s]) => t + " (" + s + ")").join(", ") : "none"));
}
report("trial balance");
ledger.push({ txn: "T3 book O2", line: 4, acct: "platform_revenue", amt: -tk(85) });  // a bug bypasses post()
report("after a buggy direct write");

T1 book O1   posted 3 lines
T2 fee O1    posted 2 lines
T3 book O2   posted 3 lines
T3 book O2   duplicate txn id, ignored
T4 refund O1 posted 3 lines
T5 payout    REJECTED: lines sum to 1500 paisa

trial balance
  gateway_clearing      820.00 Tk
  operator_payable     -765.00 Tk
  platform_revenue      -85.00 Tk
  gateway_fees           30.00 Tk
  sum of all lines           0 paisa
  unbalanced txns: none

after a buggy direct write
  gateway_clearing      820.00 Tk
  operator_payable     -765.00 Tk
  platform_revenue     -170.00 Tk
  gateway_fees           30.00 Tk
  sum of all lines       -8500 paisa
  unbalanced txns: T3 book O2 (-8500)

CREATE TABLE ledger_entries (
  txn_id       TEXT    NOT NULL,          -- e.g. 'P1-capture', idempotent
  line         INTEGER NOT NULL,
  account      TEXT    NOT NULL,
  amount_paisa BIGINT  NOT NULL CHECK (amount_paisa <> 0),
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (txn_id, line)
);
-- App role: INSERT and SELECT only. No UPDATE, no DELETE.
-- Nightly check: SELECT txn_id FROM ledger_entries
--   GROUP BY txn_id HAVING SUM(amount_paisa) <> 0;

লাইনের যোগফল-শূন্য নিয়ম এক বাক্যে ডেটাবেস পুরোপুরি চাপিয়ে দিতে পারে না (একটি লেনদেনের লাইনগুলো আলাদা সারি), তাই লেখা হয় একটি ফাংশন দিয়ে, যা আগে যোগফল যাচাই করে সব লাইন এক transaction-এ লেখে; আর রাতের যাচাই ধরে যা ফাংশন এড়িয়ে ঢুকেছে। একটি সমস্যা লুকিয়ে আছে: platform_revenue প্রায় প্রতিটি booking-এ বদলায় — একটি hot account. তার balance সারি প্রতিবার হালনাগাদ করলে সেটি অংশ ৫-এর মতোই hot row. প্রতিকার ভাবনার প্রশ্ন ৫-এ।

৯ · ভাঙন, trade-off আর বিস্তার — কী মরলে কী হয়

১০ গুণ ভিড়ে কোথায় আটকাবে

• একটি বিশাল show-এর shard: সেকশনভিত্তিক ভাগ, single-writer, আর “সেরা খালি সিট” নিজে বেছে দেওয়া (ভাবনার প্রশ্ন ১)।
• আসনহীন counter: আরও bucket; প্রতিটি bucket-এর সীমা ১ ÷ h.
• Gateway-এর নিজের সীমা: প্রদানকারীর চুক্তি থেকে, অনুমানে নয়; কয়েকটি gateway-তে ভাগ, ভর্তির হার তাতেও বাঁধা।
• SMS আর waiting room-এর খোঁজ: লাখো নিশ্চিতকরণে queue আর অগ্রাধিকার (পর্ব ৫৭); poll-এর ব্যবধান বাড়ানো বা SSE (পর্ব ১০)।

নিরাপত্তা, নজরদারি আর খরচ

নিরাপত্তা (পর্ব ৫২): webhook-এর স্বাক্ষর আর সময়-ছাপ যাচাই; কার্ডের তথ্য নিজেরা না রেখে gateway-এর পাতা ব্যবহার; refund-এর ক্ষমতা অল্প কয়েকজনের, বড় অঙ্কে দুজনের অনুমোদন (least privilege); payment চেষ্টার rate limit; ledger-এ app-এর UPDATE-DELETE-এর অধিকারই নেই।

নজরদারি (পর্ব ৫০-এর alert) — যেগুলোতে সতর্কসংকেত বাজবে:

• একই সিটে একাধিক booking — সংখ্যাটি সবসময় শূন্য থাকার কথা; একটিই মানে bug
• Ledger-এর trial balance শূন্য নয়, বা reconciliation-এ অমিল একটি সীমার বেশি
• UNKNOWN payment-এর সংখ্যা আর বয়স; gateway-এর p99 আর error-এর হার
• মেয়াদোত্তীর্ণ hold-এর অনুপাত, seat DB-র p99, outbox-এর জমা আর webhook-এর দেরি

খরচ: বিক্রির সময় জানা, তাই আগে সার্ভার বাড়ানো, পরে কমানো (পর্ব ১৩); ভিড়ের বড় অংশ edge-এর সস্তা পাতায়; ডেটাবেসের আকার ঠিক হয় ভর্তির হারে, মোট ভিড়ে নয়।

১০ · AI-এর যুগে — টিকিট আর payment-এর নকশা যাচাই

“একটি টিকিট বুকিং সিস্টেম ডিজাইন করুন” — এমন অনুরোধে AI সাধারণত দেয় microservices, Kafka, Redis lock আর Elasticsearch-এর তালিকা; কঠিন প্রশ্নগুলো — কোথায় শর্তসহ লেখা, timeout-এ কী, টাকার খাতা কেমন — প্রায়ই বাদ। চেনা ভুল:

AI-এর নকশা মানার আগে — চেকলিস্ট

• Double booking আটকানো লেখাটি seat DB-তে শর্তসহ বা UNIQUE — lock আর cache শুধু সহায়ক
• চূড়া, ভর্তির হার, ডেটাবেসের লেখা আর ভূতের hold নিজে আবার গুনেছি
• Payment-এর state machine-এ UNKNOWN আছে; প্রতিটি retry একই key-তে; reconciliation-এর পরিকল্পনা আছে
• Compensation (সিট ছাড়া, refund) শর্তসহ আর idempotent; খবর যায় outbox দিয়ে
• টাকা পয়সায় পূর্ণসংখ্যা; ledger append-only, প্রতি লেনদেনে যোগফল শূন্য
• প্রতিটি অংশ মরলে কী হয়, একটি টেবিলে লিখেছি; gateway-এর সীমা চুক্তিতে মিলিয়েছি; ছোট simulation বা load test চালিয়েছি