Systems Hub
01 / 12
সব একসাথে ধাপে ধাপে
💸

রহিম ৫০০০ টাকা পাঠাল
করিম পেল না

টাকা কোথায় গেল? এই ভয়ঙ্কর সমস্যার সমাধান হলো ACID — প্রতিটা database ব্যবহার করে, অথচ বেশিরভাগ developer জানে না কীভাবে।

❌ টাকা হারিয়ে যাওয়া ⚠️ ডেটা corrupted ✅ ACID দিয়ে সমাধান

এই slide শেষে তুমি বুঝবে কেন bank, বিকাশ, শপিং সাইট সব ACID ব্যবহার করে — এবং তোমার code-এও কীভাবে ব্যবহার করবে।

সহজ ভাষায়

ACID কী জিনিস?

🏦

ধরো বিকাশের মত একটা সিস্টেম

রহিম ৫০০০ টাকা করিমকে পাঠাচ্ছে। এই কাজে database-এ দুটো কাজ হবে: রহিমের account থেকে কমাও, করিমের account-এ যোগ করো। এখন মাঝখানে যদি server crash করে?

A
Atomicity
সব অথবা কিছুই না
C
Consistency
নিয়ম সবসময় মানে
I
Isolation
একে অপরকে দেখে না
D
Durability
একবার save = সবসময়

PostgreSQL, MySQL — সব production database এই ৪টা নিয়ম মেনে চলে। এগুলো না থাকলে কোনো financial system চলত না।

A — প্রথম অক্ষর

Atomicity — সব অথবা কিছুই না

🎬 রহিম → করিম টাকা transfer

রহিমের balance: ১০,০০০ → ৫,০০০ (কমাও)
💥 এখানে server crash! ② কখনো হলো না...
করিমের balance: ১,০০০ → ৬,০০০ (এটা হলো না)

❌ Atomicity ছাড়া

  • রহিমের ৫০০০ চলে গেল
  • করিম কিছু পেল না
  • ৫০০০ টাকা বাতাসে মিলিয়ে গেল!

✅ Atomicity সহ

  • সব কাজ একটা package
  • যেকোনো error → সব rollback
  • রহিমের টাকা ফিরে আসে
// Prisma transaction — Atomicity নিশ্চিত করে
await prisma.$transaction(async (tx) => {{'{'}}
  await tx.account.update({'{'} where: {'{'} id: rahimId {'}'}, data: {'{'} balance: {'{'} decrement: 5000 {'}'} {'}'} {'}'});
  await tx.account.update({'{'} where: {'{'} id: karimId {'}'}, data: {'{'} balance: {'{'} increment: 5000 {'}'} {'}'} {'}'});
{'}'});  // error হলে দুটোই rollback
C — দ্বিতীয় অক্ষর

Consistency — নিয়ম সবসময় মানতে হবে

🏪 জাবেরের দোকানের উদাহরণ

জাবেরের account-এ আছে ১০০ টাকা। সে ১৫০ টাকার জিনিস কিনতে চায়। নিয়ম হলো: balance কখনো শূন্যের নিচে যেতে পারবে না।

❌ Consistency ছাড়া

  • balance: ১০০ - ১৫০ = -৫০
  • database এটা allow করে
  • জাবের ঋণগ্রস্ত, দোকানদার ক্ষতিগ্রস্ত
  • পুরো financial system ভেঙে পড়ে

✅ Consistency সহ

  • constraint: CHECK (balance >= 0)
  • ১৫০ টাকার কেনাকাটা reject
  • error message: "insufficient funds"
  • নিয়ম ভাঙার উপায় নেই
Consistency নিশ্চিত করে
CHECK constraints Foreign keys UNIQUE constraints NOT NULL rules

Database নিজেই নিয়মের রক্ষক। Developer ভুল করলেও, database নিয়ম মানাবে। এটাই Consistency-র শক্তি।

I — তৃতীয় অক্ষর

Isolation — একজন আরেকজনকে দেখে না

🛒 একই সময়ে দুটো কাজ

রহিম

শেষ ১টা আইফোন কিনছে — টাকা কাটা শুরু হয়েছে, কিন্তু এখনো commit হয়নি

করিম

একই সময়ে সেই আইফোনটা দেখছে — এখনো আছে কিনা?

❌ Isolation ছাড়া

  • করিম দেখে: আইফোন আছে ✓
  • করিমও কিনে ফেলে
  • একটা phone দুজন পায়!
  • দোকান: লোকসান 😱

✅ Isolation সহ

  • রহিম কিনছে → row lock
  • করিম: "out of stock"
  • দুজন একটা পাবে না
  • MVCC দিয়ে handle

Isolation এর ৪টা Level

Read Uncommitted Read Committed Repeatable Read ★ Serializable

PostgreSQL default: Read Committed। বেশিরভাগ ক্ষেত্রে এটাই যথেষ্ট। Payment-এ Repeatable Read ব্যবহার করো।

D — চতুর্থ অক্ষর

Durability — একবার save মানে সবসময়

💡 হাচানের উদাহরণ

হাচান রাত ১১টায় order দিল। Database বলল "success" — "Transaction committed!" এর ৩ সেকেন্ড পরে server crash হলো। সকালে server চালু হলে — হাচানের order কি থাকবে?

❌ Durability ছাড়া

  • RAM-এ ছিল, crash-এ গেল
  • হাচানের order নেই
  • টাকা কেটেছে, মাল আসবে না
  • user রাগী, business ক্ষতিগ্রস্ত

✅ Durability সহ (WAL)

  • commit-এর আগে disk-এ লেখা
  • WAL log সবসময় থাকে
  • crash recovery → data পুনরুদ্ধার
  • হাচানের order safe!

WAL — Write-Ahead Log

PostgreSQL প্রতিটা change disk-এ WAL file-এ লেখে commit করার আগেই। Server crash হলে WAL দেখে exact কোথায় থামা হয়েছিল তা জানে এবং recover করে।

বাস্তব ভয়

ACID ছাড়া কী হতো?

🏦

বিকাশ/Nagad — Atomicity ছাড়া

রোজ হাজার হাজার মানুষের টাকা হারিয়ে যেত। Transfer fail হলে টাকা কোথাও না কোথাও আটকে থাকত। দেশে financial chaos।

🛒

Daraz/Amazon — Isolation ছাড়া

একটা product ১০০০ জন একসাথে কিনতে পারত। Stock ০টা হলেও বিক্রি হত। দোকান দেউলিয়া।

💾

যেকোনো সিস্টেম — Durability ছাড়া

বিদ্যুৎ গেলে সব data হারিয়ে যেত। Hospital patient record নেই। School result নেই। পুরো digital world অবিশ্বাসযোগ্য।

ACID শুধু একটা technical concept না — এটাই digital trust-এর ভিত্তি।

তোমার code-এ

কখন $transaction ব্যবহার করবে?

✅ Transaction লাগবে

  • টাকা transfer (debit + credit)
  • Order create (order + stock কমাও)
  • Registration (user + profile + role)
  • একাধিক table একসাথে update

একটা কাজ = Transaction নয়

  • শুধু profile update
  • শুধু comment post
  • একটা table-এ insert
  • Read-only query
// Order করার সময় — stock + order একসাথে
const result = await prisma.$transaction(async (tx) => {'{'}
  // stock কমাও
  await tx.product.update({'{'} where: {'{'} id {'}'}, data: {'{'} stock: {'{'} decrement: 1 {'}'} {'}'} {'}'});
  // order তৈরি করো
  return tx.order.create({'{'} data: {'{'} userId, productId, amount {'}'} {'}'});
{'}'});
// এর যেকোনো একটা fail করলে দুটোই rollback হবে

Rule of thumb: একাধিক table পরিবর্তন হলে সবসময় $transaction ব্যবহার করো।

সতর্কতা

যে ভুলগুলো সবাই করে

❌ Transaction-এর বাইরে business logic

Stock check করলে বাইরে, কেনাকাটা transaction-এর ভেতরে। মাঝখানে অন্য কেউ কিনে ফেলতে পারে।

❌ Long transaction

Transaction-এর ভেতরে API call করা। Lock ধরে রাখলে অন্যরা block হয়। ২০০ms-এর বেশি = সমস্যা।

⚠️ Error handle না করা

Transaction error ধরা না হলে user জানবে না কী হয়েছে। সবসময় try-catch দাও।

⚠️ Wrong isolation level

Financial transaction-এ Read Committed যথেষ্ট না হতে পারে। Serializable অনেক slow। Repeatable Read সাধারণত best choice।

মনে রাখো

ACID — ৪ লাইনে

A
Atomicity — সব অথবা কিছুই না
রহিমের টাকা কাটলে করিমও পাবে — নইলে কেউ পাবে না
C
Consistency — নিয়ম সবসময় মানে
জাবেরের balance কখনো ০-এর নিচে যাবে না
I
Isolation — একে অপরকে বিরক্ত করে না
রহিম-করিম দুজন একই জিনিস কিনতে পারবে না
D
Durability — একবার save সবসময় আছে
হাচানের order — crash হলেও থাকবে, WAL দিয়ে
🎯

এখন থেকে তুমি কী করবে?

  • একাধিক table update → সবসময় $transaction
  • Financial code → Repeatable Read isolation
  • Constraint database-এ রাখো, শুধু code-এ না
  • Transaction-এর ভেতরে API call করবে না
  • Error ধরো, user-কে জানাও

ACID মানলে তোমার app-এ রহিমের টাকা কখনো হারাবে না, করিম সবসময় পাবে, জাবেরের data safe থাকবে, হাচান রাতে order দিলে সকালে পাবে। ✅