Application-এ transaction — stock, order আর race condition

১ · শেষ ইলিশটি দুজনের হাতে

পহেলা বৈশাখের আগের রাত। বাজারঘরে ১ কেজির ইলিশ আছে শেষ একটি। রিনা আর রাফি একই মুহূর্তে “অর্ডার করুন” চাপলেন। দুজনের ফোনেই এলো “অর্ডার সফল”। সকালে গুদামের লোক ফোন করলেন: মাছ একটি, রসিদ দুটি। একে বলে overselling, মানে যা আছে তার চেয়ে বেশি বিক্রি করা।

কোডে ভুলটি এমন দেখায়, আর প্রথম দেখায় নির্দোষই লাগে:

const p = await prisma.product.findUniqueOrThrow({ where: { id } });
if (p.stock < qty) throw new OutOfStock();
await prisma.product.update({ where: { id }, data: { stock: p.stock - qty } });
return prisma.order.create({ data: { productId: id, buyer, qty, totalPaisa: p.pricePaisa * qty } });

একজন ক্রেতা থাকলে এই কোড নিখুঁত। সমস্যা হয় দুজনের ধাপ একে অন্যের ফাঁকে ঢুকলে। এই ফলকে বলে race condition: কার কাজ কখন শেষ হলো, তার ওপর ফল নির্ভর করছে। নিচের ডায়াগ্রামে দুজনের ধাপ পরপর দেখুন।

1Rina: SELECT stock      → 12Rafi: SELECT stock      → 13Rina: UPDATE stock = 0, order4Rafi: UPDATE stock = 0, order5গুদাম: হিসাব মেলানো

এবার একই কাহিনি কোডে। এখানে কোনো ডেটাবেস নেই, একটি object-ই “টেবিল”, আর প্রতিটি await মানে ডেটাবেসে একবার যাওয়া। এটি শেখানোর মডেল। JavaScript-এর event loop এখানে ক্রম নির্দিষ্ট রাখে, তাই আউটপুট প্রতিবার এক। সত্যিকারের ডেটাবেসে ক্রম প্রতি run-এ বদলায়।

// Teaching model: a table in memory. One await = one trip to the database.
const trip = () => new Promise((resolve) => setImmediate(resolve));
const db = { stock: 1, orders: [] };

async function checkThenWrite(name) {
  await trip();
  const stock = db.stock;                  // SELECT stock
  console.log(`${name}: read stock = ${stock}`);
  if (stock < 1) return console.log(`${name}: sold out`);
  await trip();
  db.stock = stock - 1;                    // UPDATE stock = 0
  db.orders.push(name);
  console.log(`${name}: order placed`);
}

async function atomicUpdate(name) {
  await trip();
  const count = db.stock >= 1 ? 1 : 0;     // UPDATE ... WHERE stock >= 1
  if (count === 1) { db.stock -= 1; db.orders.push(name); }
  console.log(`${name}: count = ${count}`);
}

async function run(title, buy) {
  db.stock = 1;
  db.orders = [];
  console.log(`--- ${title}`);
  await Promise.all([buy('Rina'), buy('Rafi')]);
  console.log(`stock = ${db.stock}, orders = ${db.orders.length}`);
}

run('check, then write', checkThenWrite)
  .then(() => run('one atomic update', atomicUpdate));

সত্যিকারের PostgreSQL-এ, সত্যিকারের request দিয়ে

মডেল দেখে সন্তুষ্ট হওয়া যাবে না, আসল জিনিস চালাই। Docker ছাড়াই embedded-postgres npm package একটি আসল PostgreSQL server চালাতে পারে (শুধু পরীক্ষার জন্য, আর এর version লেখার সময়ে beta চিহ্নিত)। আগে Prisma-র version দেখে নিই, কারণ latest tag সবসময় stable হয় না:

~/bazarghar$ npm view prisma dist-tags
{ ...
  next: '8.0.0-rc.10',
  prev: '7.10.1',
  latest: '8.0.0-rc.29',
  ... }
~/bazarghar$ npm install prisma@7.10.1 @prisma/client@7.10.1 @prisma/adapter-pg@7.10.1 pg
~/bazarghar$ npm install express embedded-postgres

লেখার সময়ে latest একটি release candidate, তাই এই পর্বের সব run স্থির সংস্করণ Prisma 7.10.1, PostgreSQL 18.6, Express 5.3.0 আর Node 24 দিয়ে করা (আউটপুট ছোট করা, ফোল্ডার ~/bazarghar). সেটআপের বিস্তার পর্ব ৩৯-এর বিষয়। পরীক্ষাটি এমন: Express server, একটি পণ্য, stock = 1, আর ২০টি POST /orders একসাথে fetch দিয়ে। প্রতিটি কৌশল ১০ বার।

~/bazarghar$ npx tsx src/race.ts
stock=1 buyers=20 trials=10
strategy      sold(min..max) oversold-trials finalStock(last)
naive         13..20         10              0

এটি একটি স্থানীয় run-এর ফল, সাধারণ নিয়ম নয়। তবু দেখুন: ১০ বারের ১০ বারই oversell, আর একটি ইলিশের জন্য ১৩ থেকে ২০টি অর্ডার। আর শেষের stock দেখাচ্ছে 0, একদম সুন্দর।

২ · $transaction: দুই রূপ, আর repository পর্যন্ত পৌঁছানো

পর্ব ২৯-এ আমরা একটি ফাঁক রেখে এসেছিলাম: stock কমল, অর্ডার লেখার সময় ভাঙল, ২ প্যাকেট চাল হিসাব থেকে উধাও। সমাধান transaction, মানে কয়েকটি কাজের দল যা হয় সব হবে, নয়তো একটিও না। ACID আর isolation-এর তত্ত্ব আছে Transaction ও ACID পর্বে। এখানে শুধু অ্যাপের কোড।

Prisma Client-এ $transaction-এর দুটি রূপ। Array রূপে আগে থেকে জানা query-গুলোর তালিকা দেন, Prisma সেগুলো ক্রমে একটি transaction-এ চালায়:

const [product, order] = await prisma.$transaction([
  prisma.product.update({ where: { id }, data: { stock: { decrement: 1 } } }),
  prisma.order.create({ data: { productId: id, buyer: 'rina', qty: 1, totalPaisa: 42000, idempotencyKey: 'k-1' } }),
]);

মাঝে কোনো যুক্তি চলে না: প্রথম query-র ফল দেখে দ্বিতীয়টি ঠিক করা যায় না। Interactive transaction-এ একটি async function দেন। Prisma আপনাকে একটি tx দেয়, যা একটি connection-এ বাঁধা:

await prisma.$transaction(async (tx) => {
  await tx.product.update({ where: { id }, data: { stock: { decrement: 1 } } });
  if (somethingWrong) throw new Error('business rule failed'); // ROLLBACK
  await tx.order.create({ data: orderData });
}, { maxWait: 2000, timeout: 5000 });                          // defaults

Function স্বাভাবিকভাবে শেষ হলে commit, আর error ছুড়লে rollback. Isolation level, maxWait আর timeout দ্বিতীয় argument-এ যায়। সত্যিকারের run-এ দুটি রূপই পরীক্ষা করলাম। দ্বিতীয় array-তে order-এর idempotencyKey ইচ্ছা করে একই রাখা হয়েছে, তাই সেটি ভাঙে:

ok: stock 4 order true
second failed: code P2002
  Unique constraint failed on the constraint: `Order_idempotencyKey_key`
stock after rollback 4 orders 1
thrown: business rule failed
stock after throw 4

দ্বিতীয় array-র প্রথম query stock কমিয়েছিল, কিন্তু order ভাঙায় সেটিও ফিরে গেল, stock 4-ই থাকল। Interactive রূপেও তাই।

thrown: payment record failed
stock 5 orders 1

Repository পর্যন্ত tx পৌঁছে দেওয়া

পর্ব ২৯-এর টানাপোড়েনটি মনে আছে? Transaction শুরু করে ডেটাবেস, কিন্তু কোন কাজগুলো একসাথে তা জানে service layer. সরল পথ: repository-র প্রতিটি method প্রথম parameter-এ transaction client নেবে, আর service সেটি পাঠাবে।

type Db = Prisma.TransactionClient;

export const orderRepo = {
  async reserveStock(db: Db, productId: number, qty: number) {
    const r = await db.product.updateMany({
      where: { id: productId, stock: { gte: qty } },
      data: { stock: { decrement: qty } },
    });
    return r.count === 1;
  },
  createOrder(db: Db, data: NewOrder) {
    return db.order.create({ data });
  },
};

// service: boundary here, SQL in the repository
export function placeOrder(productId: number, buyer: string, qty: number, pricePaisa: number) {
  return prisma.$transaction(async (tx) => {
    if (!(await orderRepo.reserveStock(tx, productId, qty))) throw new OutOfStock();
    return orderRepo.createOrder(tx, { productId, buyer, qty, totalPaisa: pricePaisa * qty });
  });
}

পর্ব ২৯-এর ফাঁকটি এবার আসল ডেটাবেসে পরীক্ষা করি। চাল ৩ প্যাকেট। রিনা ২টি নিলেন। রাফির অর্ডার লেখার পরে ইচ্ছা করে disk full ছোড়া হলো:

order 2 84000 stock 1
failed: disk full
after failure: stock 1 orders 1

রাফির ১ প্যাকেট আর হারাল না, stock 1-ই থাকল। মোট দাম পয়সায় পূর্ণসংখ্যা: 84000 মানে ৳৮৪০।

৩ · Transaction থাকলেও কেন oversell

স্বাভাবিক ধারণা: naive কোডটি $transaction-এ মুড়ে দিলেই race শেষ। পরীক্ষা করি। প্রথম কোডে শুধু tx বসালাম (txRead), আর আরেকটিতে লেখার সময় decrement (txDecrement):

strategy      sold(min..max) oversold-trials finalStock(last)
naive         13..20         10              0
txRead        10..10         10              0
txDecrement   10..10         10              -9

Transaction থাকা সত্ত্বেও ১০ বারের ১০ বারই oversell. কারণ PostgreSQL-এর ডিফল্ট isolation level হলো Read Committed (run-এ SHOW transaction_isolation দেখাল read committed). এই level-এ প্রতিটি statement তার শুরুর মুহূর্তের commit হওয়া ডেটা দেখে। Transaction “সব হবে বা কিছুই না” নিশ্চিত করে, কিন্তু আপনার পড়া মানটিকে আগলে রাখে না। SELECT কোনো lock নেয় না, তাই দশটি transaction একসাথে পড়ল 1, দশটিই যাচাই পাস করল।

txDecrement-এ দেখুন -9. stock - 1 ডেটাবেসে হিসাব হয়, তাই কোনো update হারায়নি: ১ থেকে ১০ বার কমে −৯. এই ক্ষেত্রে অন্তত ভুলটি চোখে পড়ে। আর txRead-এ stock 0, বাগটি লুকিয়ে আছে।

pool 1   sold 1..1     oversold in 0 of 10 trials
pool 3   sold 3..3     oversold in 10 of 10 trials
pool 10  sold 10..10   oversold in 10 of 10 trials
pool 20  sold 18..19   oversold in 10 of 10 trials

৪ · সমাধান: যাচাই আর লেখা এক SQL-এ, আর ডেটাবেসের নিয়ম

ফাঁক থাকলে সমস্যা, তাই ফাঁকটিই তুলে দিন। যাচাইটি UPDATE-এর WHERE-এ চলে যাক। এটিই conditional update. Prisma-তে update নয়, updateMany, কারণ এটি কয়টি সারি বদলাল তা count-এ জানায়:

await prisma.$transaction(async (tx) => {
  const r = await tx.product.updateMany({
    where: { id, stock: { gte: qty } },
    data: { stock: { decrement: qty } },
  });
  if (r.count === 0) throw new OutOfStock();   // HTTP 409
  const p = await tx.product.findUniqueOrThrow({ where: { id } });
  return tx.order.create({ data: { productId: id, buyer, qty, totalPaisa: p.pricePaisa * qty } });
});

Prisma আসলে কী পাঠায়, query log চালু করে দেখা যাক (সত্যিকারের run, log: ['query']):

prisma:query UPDATE "public"."Product" SET "stock" = ("public"."Product"."stock" - $1)
             WHERE ("public"."Product"."id" = $2 AND "public"."Product"."stock" >= $3)
count = 1
prisma:query COMMIT

একটিই statement, মান parameter হিসেবে। দ্বিতীয় ক্রেতা সারির lock পেতে অপেক্ষা করে, তারপর নতুন stock 0-তে শর্ত যাচাই হয়, 0 >= 1 মিথ্যা, count হয় 0. একই পরীক্ষা:

strategy      sold(min..max) oversold-trials finalStock(last) statuses(all)
atomic        1..1           0               0                {"201":10,"409":190}

১০ বারে ১০ জন সফল, বাকি ১৯০ জন পেলেন 409, কোনো oversell নেই। নিচের ব্লকে SQL-এর গড়নটি নিজে চালান। তবে সৎভাবে বলি: এটি browser-এর ভেতরে SQLite, এখানে কোনো সত্যিকারের concurrency নেই, statement দুটি একটির পর একটি চলে। এটি শুধু SQL-টির আকার আর count-এর ধারণা দেখায়।

-- Rina: the check lives inside the UPDATE
UPDATE products SET stock = stock - 1
WHERE id = 1 AND stock >= 1;
SELECT changes() AS rina_count;

-- Rafi: same statement, stock is already 0
UPDATE products SET stock = stock - 1
WHERE id = 1 AND stock >= 1;
SELECT changes() AS rafi_count;

SELECT name, stock FROM products;

Unique constraint: দুবার হওয়া ঠেকানো

কিছু race-এ stock নয়, “একই জিনিস দুবার” হওয়াই সমস্যা, যেমন ক্রেতার দুবার ক্লিক। পর্ব ৩৩-এর idempotency key মনে করুন। আগে খুঁজে তারপর লেখা আবার সেই একই পড়ে-যাচাইয়ের ভুল। বরং ডেটাবেসকে বলুন idempotencyKey String? @unique, লিখতে চেষ্টা করুন, আর P2002 ধরুন। একই key-তে পাঁচটি request একসাথে (সত্যিকারের run, stock 5):

try {
  const order = await prisma.$transaction(async (tx) => {
    /* conditional updateMany, then */
    return tx.order.create({ data: { /* ... */ idempotencyKey: key } });
  });
  return { status: 201, id: order.id };
} catch (e: any) {
  if (e.code !== 'P2002') throw e;     // transaction already rolled back
  const o = await prisma.order.findUniqueOrThrow({ where: { idempotencyKey: key } });
  return { status: 200, id: o.id };
}

[ { status: 201, id: 3134 }, { status: 200, id: 3134 }, { status: 200, id: 3134 },
  { status: 200, id: 3134 }, { status: 200, id: 3134 } ]   (ছোট করা)
stock 4 orders 1

অর্ডার ১টি, stock কমল ১, চারটি duplicate পেল আগের অর্ডারের id. হেরে যাওয়া transaction-এর stock কমানোও ফিরে গেছে।

শেষ পাহারা: CHECK constraint

কোডে ভুল থাকলেও stock যেন ঋণাত্মক না হয়, সেই নিয়ম ডেটাবেসে রাখুন। Prisma schema-তে CHECK লেখা যায় না, তাই হাতে লেখা migration লাগে (migration-এর পথ পর্ব ৪০-এ):

ALTER TABLE "Product" ADD CONSTRAINT "stock_non_negative" CHECK ("stock" >= 0);

এবার ভুল কোড txDecrement তিনটি transaction-এ চালালাম (stock 1):

1 ok
2 P2039 Database error. Code: `23514`. Message: `new row for relation "Product"
  violates check constraint "stock_non_negative"`
3 P2039 Database error. Code: `23514`. ...
stock 0

এটি সমাধান নয়, পাহারা। Error আসে, ক্রেতা বিরক্ত হন, কিন্তু হিসাব ভাঙে না। Run-এ Prisma-র code ছিল P2039, আর ভেতরে PostgreSQL-এর 23514. Prisma 7-এর error reference-এ constraint ভাঙার জন্য P2004 লেখা আছে, আর P2039 লেখার সময়ে সেই তালিকায় নেই। Prisma-র ২০২৬ সালের এপ্রিলের changelog অনুযায়ী P2039 হলো সাধারণ “Database error”: driver এমন কোনো error দিলে, যার নির্দিষ্ট Prisma code নেই, Prisma সেটিকে এই code-এ মুড়ে দেয়। তাই আসল কারণ বুঝতে ভেতরের database code, এখানে 23514, দেখতে হয়। নির্দিষ্ট code ধরে কোড লেখার আগে নিজের version-এ চালিয়ে দেখুন।

৫ · SELECT … FOR UPDATE: সারিতে তালা

সব কাজ এক UPDATE-এ আঁটে না। ধরুন পড়ার পরে জটিল হিসাব লাগে: ক্রেতার ধরন, ছাড়, সীমা। তখন পড়ার সময়েই সারিটি আটকে দিন। একে বলে pessimistic locking: সংঘাত হবেই ধরে নিয়ে আগেই row lock নেওয়া। Prisma-র query API-তে এর সরাসরি option নেই, তাই raw SQL. $queryRaw tagged template, তাই মান parameter হয়ে যায়, injection-এর ভয় নেই:

await prisma.$transaction(async (tx) => {
  const [p] = await tx.$queryRaw<{ id: number; stock: number; pricePaisa: number }[]>`
    SELECT id, stock, "pricePaisa" FROM "Product" WHERE id = ${id} FOR UPDATE`;
  if (p.stock < qty) throw new OutOfStock();
  await tx.product.update({ where: { id }, data: { stock: p.stock - qty } });
  return tx.order.create({ data: { productId: id, buyer, qty, totalPaisa: p.pricePaisa * qty } });
});

এবার মিলিয়ে দেখুন tx.$queryRaw, prisma.$queryRaw নয়: lock থাকে transaction শেষ হওয়া পর্যন্ত, তাই transaction-এর বাইরে FOR UPDATE অর্থহীন। A 500 ms ধরে lock রাখল, B মাঝখানে এলো। সত্যিকারের run-এর সময়-চিহ্ন:

   1ms A got lock, stock 1
  55ms B asks for lock
 511ms A updated, committing
 512ms B got lock, stock 0

1A: SELECT ... FOR UPDATE → 12B: SELECT ... FOR UPDATE ...3A: UPDATE stock = 04A: COMMIT5B: stock 0, sold out, ROLLBACK

২০ ক্রেতার পরীক্ষায় forUpdate-এর ফল 1..1, oversell ০ বার। দাম হলো অপেক্ষা: সবাই লাইনে দাঁড়ায়। মনে রাখুন, FOR UPDATE-এর একটি ভাই আছে, FOR UPDATE SKIP LOCKED, যা আটকানো সারি ফেলে পরেরটি ধরে। কাজের queue আর outbox-এ এটি লাগবে (অংশ ৯)। Lock-এর তত্ত্ব আছে Concurrency control পর্বে।

৬ · Lock ছাড়া: version column আর Serializable

Optimistic locking

Optimistic concurrency উল্টোভাবে ভাবে: সংঘাত কম হবে, তাই lock নয়। পড়ার সময় একটি version column-এর মান মনে রাখুন, আর লেখার সময় শর্ত দিন “version এখনো সেটিই”। না মিললে কেউ আগে লিখেছে, আবার চেষ্টা করুন। If-Match আর ETag-এর (পর্ব ৩৩) ডেটাবেস-রূপ এটি।

// Teaching model: optimistic locking with a version column.
const trip = () => new Promise((resolve) => setImmediate(resolve));
const product = { stock: 2, version: 0 };

// UPDATE ... SET stock = stock - 1, version = version + 1
// WHERE version = seen. Returns how many rows changed.
function updateIfVersion(seen) {
  if (product.version !== seen) return 0;
  product.stock -= 1;
  product.version += 1;
  return 1;
}

async function buy(name, maxTries = 4) {
  for (let attempt = 1; attempt <= maxTries; attempt++) {
    await trip();
    const { stock, version } = product;    // read, no lock
    if (stock < 1) return console.log(`${name}: sold out`);
    await trip();
    if (updateIfVersion(version) === 1) {
      return console.log(`${name}: bought on try ${attempt}, version ${version} -> ${version + 1}`);
    }
    console.log(`${name}: version ${version} is old, retry`);
  }
  console.log(`${name}: gave up, answer 503`);
}

Promise.all([buy('Rina'), buy('Rafi'), buy('Mina')]).then(() => {
  console.log(`stock = ${product.stock}, version = ${product.version}`);
});

Prisma-তে একই কাজ updateMany আর where: { id, version: p.version } দিয়ে, data-তে version: { increment: 1 }, আর count === 0 হলে retry.

Serializable আর P2034

তৃতীয় পথ: কোড বদলাবেন না, ডেটাবেসকেই বলুন Serializable level-এ চলতে। PostgreSQL তখন সমান্তরাল transaction-গুলো পাহারা দেয়, আর ফল একে একে চলার মতো না হলে একটিকে বাতিল করে। Prisma-তে এই বাতিলের নাম P2034, আর Prisma নিজে retry করে না, সে দায়িত্ব আপনার। Retry করতে হবে পুরো transaction, শুধু শেষ লাইন নয়:

export async function withRetry<T>(fn: () => Promise<T>, attempts = 4): Promise<T> {
  for (let i = 1; ; i++) {
    try {
      return await fn();
    } catch (e) {
      const retryable = e instanceof Prisma.PrismaClientKnownRequestError && e.code === 'P2034';
      if (!retryable || i === attempts) throw e;
      await sleep(20 * 2 ** i * Math.random());   // backoff with jitter
    }
  }
}

await withRetry(() => prisma.$transaction(async (tx) => {
  const p = await tx.product.findUniqueOrThrow({ where: { id } });
  if (p.stock < qty) throw new OutOfStock();
  await tx.product.update({ where: { id }, data: { stock: p.stock - qty } });
  return tx.order.create({ data: orderData });
}, { isolationLevel: Prisma.TransactionIsolationLevel.Serializable }));

এখানে exponential backoff আর jitter কাজে লাগে, যাতে সবাই একসাথে আবার ধাক্কা না দেয়। সত্যিকারের run: stock 3, চার ক্রেতা একসাথে।

[ 'ok', 'ok', 'ok', 'OUT_OF_STOCK' ] retried 5
stock 0 orders 3
-- from a separate two-transaction run:
code: 'P2034'
msg: 'Transaction failed due to a write conflict or a deadlock. Please retry your transaction'

কোনটি কখন: একই পরীক্ষায় তুলনা

১ stock-এ সবাই ঠিক ছিল (optimistic আর serializable-ও 1..1). এবার কঠিন পরীক্ষা: একই সারিতে stock 50, ক্রেতা 50, সবার পাওয়ার কথা। ৫ বার করে, এক স্থানীয় run. “ব্যর্থ” মানে retry শেষ করে 503.

শিক্ষাটি এই: গরম সারিতে retry-নির্ভর পথ হয় ধীর, নয়তো পণ্য থাকা সত্ত্বেও “ব্যর্থ”। atomic আর forUpdate-এর ms-এর পার্থক্যকে গুরুত্ব দেবেন না; এই এক run-এ এত ছোট ব্যবধান কিছু প্রমাণ করে না, আর atomic কোডে একটি বাড়তি পড়াও ছিল।

৭ · Deadlock: উল্টো ক্রমের দুই কার্ট

রিনার কার্টে আগে চাল, পরে ডাল। রাফির কার্টে আগে ডাল, পরে চাল। দুজনের transaction প্রতিটি পণ্যের stock কমাচ্ছে, মানে সারি আটকাচ্ছে। রিনা চালের সারি ধরে ডালের জন্য অপেক্ষা করছেন, রাফি ডালের সারি ধরে চালের জন্য। কেউ ছাড়বে না। সরু গলিতে দুই রিকশা মুখোমুখি, কেউ পিছোবে না।

PostgreSQL এটি ধরে ফেলে: lock-এর অপেক্ষা deadlock_timeout (এখানে ডিফল্ট 1s) পেরোলে সে যাচাই করে, চক্র পেলে একটি transaction-কে বাতিল করে। সত্যিকারের run:

A locked chal
B locked dal
A locked dal
ms 1119
A fulfilled
B rejected  code: 'P2034'
  msg: 'Transaction failed due to a write conflict or a deadlock. Please retry your transaction'
stock [ { slug: 'chal-5kg', stock: 99 }, { slug: 'dal-1kg', stock: 99 } ]

সময় লাগল ১.১ সেকেন্ডের বেশি, যদিও কাজ ছিল ১০০ ms-এর। আর আগের অংশের সেই P2034-ই এখানে। Prisma-র বার্তাতেই লেখা “write conflict or a deadlock”, তাই আগের withRetry এখানেও কাজ করে। কিন্তু আসল ওষুধ হলো lock ordering: সবাই একই ক্রমে lock নেবে। মডেলে দেখুন:

// Teaching model: row locks with deadlock detection. Fixed order, no database.
const trip = () => new Promise((resolve) => setImmediate(resolve));
let holder, queue;

function lock(tx, row) {
  if (!holder[row]) { holder[row] = tx; return Promise.resolve(); }
  if (Object.values(queue).some((w) => w.tx === holder[row])) {
    return Promise.reject(new Error(`${tx} aborted: deadlock on ${row}`));
  }
  return new Promise((resolve) => { queue[tx] = { tx, row, resolve }; });
}
function releaseAll(tx) {
  for (const row of Object.keys(holder)) if (holder[row] === tx) delete holder[row];
  for (const w of Object.values(queue)) if (!holder[w.row]) {
    holder[w.row] = w.tx; delete queue[w.tx]; w.resolve();
  }
}
async function cart(tx, rows) {
  try {
    for (const row of rows) {
      await lock(tx, row);
      console.log(`${tx} locked ${row}`);
      await trip();
    }
    console.log(`${tx} commit`);
  } catch (e) { console.log(e.message); }
  releaseAll(tx);
}
async function run(title, a, b) {
  holder = {}; queue = {};
  console.log(`--- ${title}`);
  await Promise.all([cart('A', a), cart('B', b)]);
}
run('opposite order', ['chal', 'dal'], ['dal', 'chal'])
  .then(() => run('sorted order', ['chal', 'dal'], ['chal', 'dal']));

বাস্তব কোডে এটি এক লাইন: items.sort((a, b) => a.productId - b.productId). ১০টি কার্ট, অর্ধেক উল্টো ক্রমে, প্রতিটিতে ২ পণ্য, সত্যিকারের PostgreSQL-এ:

{ sorted: false, ok: 3,  deadlockAborts: 7, other: null, ms: 6142 }
{ sorted: true,  ok: 10, deadlockAborts: 0, other: null, ms: 313 }

আরেক run-এ অক্রমে ফল ছিল ok: 5, deadlockAborts: 5, ms: 3178, মানে সংখ্যাটি বদলায়। ক্রমে সাজালে দুই run-এই ০ deadlock, প্রায় ৩১৫ ms. একটি sort এই দুই run-এ সময় প্রায় ১০ থেকে ২০ গুণ কমাল, আর ব্যর্থতা শূন্য করল।

৮ · Transaction ছোট রাখুন, আর অর্ডারের পুরো পথ

Prisma-র docs স্পষ্ট বলে: transaction ছোট রাখুন, আর ভেতরে network request এড়িয়ে চলুন। কেন? Transaction খোলা মানে তিনটি জিনিস আটকে আছে: একটি pool connection, ধরা সারির lock, আর (ভাঙলে) পুরো কাজ। Payment gateway ধীর হলে আপনার ডেটাবেসও ধীর।

Gateway-কে ৩০০ ms-এর ঘুম দিয়ে নকল করা হলো (আসল সেবা নয়)। একই সারিতে ১০ ক্রেতা, সত্যিকারের run:

{ gateway: 'inside transaction', buyers: 10, totalMs: 3050 }
{ gateway: 'after commit',       buyers: 10, totalMs: 313 }

হিসাবটি সহজ। সারিটি যতক্ষণ ধরা, ততক্ষণ পরের ক্রেতা বসে। তাই গরম সারিতে:

মাপা ৩০৫০ ms এই হিসাবের সাথে মিলে যায়। এবার pool-এর দিক। Pool ৫, ২০ request, gateway ৮০০ ms, দুটি সারি পালা করে, maxWait ডিফল্ট ২০০০ ms:

{ gateway: 'inside',       pool: 5, requests: 20, ok: 9,  errs: { P2028: 11 }, ms: 4077 }
{ gateway: 'after commit', pool: 5, requests: 20, ok: 20, errs: {},            ms: 850 }

৯ সংখ্যাটিও হিসাব করা যায়। শুরুতে ৫টি connection পায়। দুটি সারি, তাই প্রতি ০.৮ s-এ ২টি শেষ হয়ে ২টি connection ছাড়ে। ০.৮ s আর ১.৬ s-এ ২টি করে নতুন ঢোকে: ৫ + ২ + ২ = ৯. পরের সুযোগ ২.৪ s-এ, কিন্তু বাকি ১১টি ২ s-এই maxWait পেরিয়ে P2028 পেয়েছে। ৯টি কাজ দুই সারিতে: ৫ পালা × ০.৮ s = ৪ s, মাপা ৪০৭৭ ms.

Timeout-এর দিকটিও দেখুন। Transaction ভেতরে ৬ সেকেন্ড ঘুমালে (ডিফল্ট timeout ৫০০০ ms), আর pool পূর্ণ থাকলে:

code: 'P2028', timeout: 5000, timeTaken: 6005
msg: 'Transaction API error: A query cannot be executed on an expired transaction. ...'
stock 5 orders 0

code: 'P2028'
msg: 'Transaction API error: Unable to start a transaction in the given time.'

একই P2028, দুটি আলাদা ঘটনা। প্রথমটি সময় পেরিয়েছে, stock ফিরে গেছে। দ্বিতীয়টিতে connection-ই মেলেনি। timeout বাড়িয়ে পার পাওয়া প্রলোভন, কিন্তু আসল ওষুধ transaction ছোট করা।

অর্ডারের পথ: তিনটি ছোট transaction, মাঝে টাকা

তাহলে টাকা নেওয়া আর stock ধরা জুড়বেন কীভাবে? উত্তর stock reservation: একটি বড় transaction নয়, একাধিক ছোট transaction, মাঝে অর্ডারের অবস্থা PENDING. হোটেলের রিসেপশনে ঘর “ধরে রাখা” হয়, অগ্রিম এলে নিশ্চিত, না এলে ১৫ মিনিট পরে ছেড়ে দেওয়া।

const confirm = (id: number) => prisma.$transaction(async (tx) => {
  const r = await tx.order.updateMany({ where: { id, status: 'PENDING' }, data: { status: 'PAID' } });
  if (r.count === 0) return false;              // already decided
  await tx.outboxEvent.create({ data: { type: 'order.paid', payload: { orderId: id } } });
  return true;
});

const release = (id: number, productId: number, qty: number) => prisma.$transaction(async (tx) => {
  const r = await tx.order.updateMany({ where: { id, status: 'PENDING' }, data: { status: 'CANCELLED' } });
  if (r.count === 0) return false;              // never return stock twice
  await tx.product.update({ where: { id: productId }, data: { stock: { increment: qty } } });
  return true;
});

লক্ষ করুন: অবস্থার বদলও conditional update. চাল ৩ প্যাকেট দিয়ে সত্যিকারের run:

reserve rina 2 -> stock 1 PENDING
reserve rafi 1 -> stock 0 PENDING
reserve mina 1 -> OUT_OF_STOCK
pay rina ok -> confirm true stock 0
pay rafi declined -> release true stock 1
late webhook for rafi -> confirm false stock 1
repeat webhook rina -> confirm false outbox 1

একই webhook দুবার এলেও outbox-এ ১টি event. Payment gateway-এর webhook-এর পূর্ণ পথ পর্ব ৬৫-এ, আর মেয়াদ-শেষের sweeper চালানো পর্ব ৬২-তে। এবার সবচেয়ে কঠিন race: ঠিক মেয়াদ শেষের মুহূর্তে confirm আর release একসাথে। ২০০টি অর্ডারে দুটিই একসাথে চালালাম:

{ confirmed: 100, released: 100, both: 0, neither: 0, paid: 100, stock: 100, expectedStock: 100 }

একটি অর্ডারেও দুটি একসাথে জেতেনি, stock ঠিক ১০০. (এই run-এ যে আগে পৌঁছেছে সে-ই জিতেছে, আর ক্রম সমান ভাগে সাজানো ছিল বলে ১০০-১০০।)

৯ · Service পেরোলে transaction নেই: outbox

অর্ডার ডেটাবেসে, আর email পাঠায় অন্য একটি service. Microservices হোক বা শুধু একটি message broker, ডেটাবেসের COMMIT বাইরের জিনিসকে ছুঁতে পারে না। দুই জায়গায় পরপর লেখাকে বলে dual write, আর এতে দুটির একটি হারাতে পারে। সত্যিকারের run: ৩টি অর্ডার, প্রথম publish-এ broker অচল।

dual write: order 1 saved, publish failed: broker unreachable
dual write: orders 3 events 2

সমাধান transactional outbox: বাইরে পাঠানোর বদলে event-টি একই transaction-এ নিজের ডেটাবেসেরই একটি টেবিলে লিখুন। অর্ডার আর event এখন এক ডেটাবেসে, তাই একসাথে হয় বা একসাথে যায়। আলাদা একটি relay পরে সেটি পাঠায়।

INSERT Order        id=101  status=PENDING
INSERT OutboxEvent  id=7    order.created  publishedAt=NULL

Order        id=101
OutboxEvent  id=7   publishedAt=NULL

SELECT id FROM "OutboxEvent"
WHERE "publishedAt" IS NULL
ORDER BY id LIMIT 5
FOR UPDATE SKIP LOCKED

publish(event 7)                 ok
-- crash here: publishedAt still NULL --
UPDATE ... SET "publishedAt" = now()

INSERT INTO processed_events (event_id) VALUES (7);
-- unique violation? already done, skip

সত্যিকারের run: ৩০টি অর্ডার, দুটি relay একসাথে, আর একটি relay প্রথম batch পাঠিয়ে চিহ্ন দেওয়ার আগে crash করল।

R1 relay crashed before marking
{ events: 30, sends: 35, uniqueEvents: 30, duplicates: 5,
  perRelay: { R1: 15, R2: 20 }, unpublished: 0 }

৩০টি event-এর একটিও হারায়নি, কিন্তু ৫টি দুবার গেছে, ঠিক crash করা batch-টি। Relay যদিও publish-এর সময় একটি transaction খোলা রাখে, সেই lock শুধু outbox-এর সারিতে, ক্রেতার stock-এর সারিতে নয়। Batch ছোট রাখুন। Polling-এর বদলে কেউ কেউ ডেটাবেসের change log পড়ে (change data capture), সে আরেক ট্রেড-অফ।

১০ · AI-এর যুগে: concurrency-র কোড যাচাই

AI-এর লেখা অর্ডার কোড প্রায়ই পরিষ্কার দেখায়, আর এক ব্যবহারকারীর test-এ পাস করে। ঠিক এই কারণেই এই জায়গাটি বিপজ্জনক: বাগ দেখা যায় শুধু চাপে।

AI-এর transaction কোড হাতে পেলে

• Pool ১ নয়, ডিফল্ট pool-এ concurrent request দিয়ে নিজে চালিয়েছি, আর অর্ডারের সংখ্যা গুনেছি
• Stock-এর চেয়ে বেশি ক্রেতার পরীক্ষায় orders <= stock মিলেছে, শুধু শেষের stock দেখে থামিনি
• Callback-এর ভেতরে সব query tx দিয়ে, কোনো network call নেই
• একাধিক সারি হলে একই ক্রমে lock নেওয়া হয়
• P2034 আর P2002 নিজের version-এ ঘটিয়ে দেখেছি, retry-র সীমা আছে
• Diff পড়েছি, অচেনা package বা হাতে বাড়ানো timeout নেই, আর secret পেস্ট করিনি