Transaction Basics

🏦 NoSQL Transactions: The Bank Vault Adventure

Imagine you’re a bank manager. Every day, people move money around. The golden rule? Never lose anyone’s money, even if the lights go out mid-transfer. That’s exactly what transactions do in databases!

🎯 What Are Transactions?

A transaction is like a promise: “I will do ALL these steps together, or NONE of them.”

Think of buying a toy with your allowance:

1. You hand over $5
2. The shopkeeper gives you the toy

What if you gave $5, but the shopkeeper walked away before giving the toy? Disaster! A transaction makes sure both steps happen together, or neither does.

⚛️ Atomic Operations

The “All-or-Nothing” Magic

Atomic means “cannot be split.” Like an atom (the smallest thing!).

// Atomic: This happens completely or not at all
db.accounts.updateOne(
  { user: "Alice" },
  { $inc: { balance: -50 } }
)

Real Life Example:

• You press “Send” on a text message
• Either the WHOLE message sends, or NOTHING sends
• You never see half a message appear!

Why It Matters

💡 Key Insight: Atomic operations are like a light switch—ON or OFF, never stuck in between.

🔢 Atomic Counters

The Like Button Problem

Imagine 1000 people click “Like” at the exact same moment. Without atomic counters, chaos happens!

// WRONG WAY (not atomic)
let likes = getLikes()     // likes = 100
likes = likes + 1          // likes = 101
saveLikes(likes)           // saves 101

// But what if 2 people did this at once?
// Person A: gets 100, adds 1, saves 101
// Person B: gets 100, adds 1, saves 101
// Result: 101 (should be 102!) 😱

// RIGHT WAY (atomic counter)
db.posts.updateOne(
  { _id: "post123" },
  { $inc: { likes: 1 } }
)
// This is ONE unbreakable step!
// 1000 people click = exactly 1000 added ✅

Where You See This

• 👍 Like/upvote buttons
• 👀 View counters on videos
• 🛒 “Only 3 left in stock!” counters
• 📊 Real-time score updates

🎮 Think of it like: A turnstile at a stadium. Each person goes through one-by-one. The counter can’t miss anyone!

📚 Multi-Document Transactions

When One Document Isn’t Enough

Sometimes you need to change multiple things together.

The Online Store Example:

When you buy a book:

1. Remove $20 from your wallet
2. Add $20 to the store’s account
3. Mark the book as “sold”
4. Create a receipt

ALL FOUR must happen together!

// Multi-document transaction
const session = db.startSession()
session.startTransaction()

try {
  // Step 1: Deduct from buyer
  db.wallets.updateOne(
    { user: "You" },
    { $inc: { balance: -20 } },
    { session }
  )

  // Step 2: Add to seller
  db.wallets.updateOne(
    { user: "BookStore" },
    { $inc: { balance: 20 } },
    { session }
  )

  // Step 3: Mark book sold
  db.books.updateOne(
    { _id: "book456" },
    { $set: { status: "sold" } },
    { session }
  )

  // All good? Make it permanent!
  session.commitTransaction()

} catch (error) {
  // Something wrong? Undo everything!
  session.abortTransaction()
}

The Magic Word: “Session”

A session is like a shopping cart:

• You add items (changes)
• Nothing is final until checkout (commit)
• You can abandon the cart anytime (abort)

graph TD
    A["Start Transaction"] --> B["Change Document 1"]
    B --> C["Change Document 2"]
    C --> D["Change Document 3"]
    D --> E{All OK?}
    E -->|Yes| F["COMMIT - Save All!"]
    E -->|No| G["ABORT - Undo All!"]

🌍 Distributed Transactions

When Your Data Lives in Different Cities

Imagine your bank has:

• Server in New York (your account)
• Server in Tokyo (friend’s account)

You send $100 to your friend in Japan. Both servers must agree!

New York Server          Tokyo Server
     |                        |
     |   "Ready to remove     |
     |    $100 from Account?" |
     |----------------------->|
     |                        |
     |   "Ready to add        |
     |    $100 to Friend?"    |
     |<-----------------------|
     |                        |
     |   "Both ready? GO!"    |
     |<======================>|
     |                        |
   ✅ Done                   ✅ Done

The Challenge

• Networks can fail
• Servers can crash
• Messages can get lost

Distributed transactions handle all these problems!

🌐 Real Example: When you buy something on Amazon, your payment (Bank A), inventory (Warehouse B), and shipping (Service C) all update together across different systems.

🤝 Two-Phase Commit (2PC)

The Wedding Ceremony Protocol

Two-Phase Commit is like a wedding:

Phase 1: “Do you take this transaction?”

• Priest asks Bride: “Do you commit?”
• Priest asks Groom: “Do you commit?”
• Both must say “I do” to proceed

Phase 2: “I now pronounce you… committed!”

• If both said yes → Wedding complete!
• If anyone said no → Wedding cancelled!

graph TD
    A["Coordinator"] --> B["Phase 1: PREPARE"]
    B --> C["Ask Server 1: Ready?"]
    B --> D["Ask Server 2: Ready?"]
    C --> E{All say YES?}
    D --> E
    E -->|Yes| F["Phase 2: COMMIT"]
    E -->|No| G["Phase 2: ABORT"]
    F --> H["Tell all: Save it!"]
    G --> I["Tell all: Forget it!"]

How It Works in Code

// PHASE 1: Prepare
coordinator.askAll("Are you ready to commit?")

// Server 1: "Yes, I'm ready!"
// Server 2: "Yes, I'm ready!"

// PHASE 2: Commit (if all said yes)
coordinator.tellAll("COMMIT!")

// All servers make changes permanent

The Problem It Solves

🎭 Remember: Two phases = Ask first, then act. Never act without asking everyone!

🔒 Transaction Isolation Levels

The Library Reading Room Problem

Imagine a library where everyone reads the SAME book. What rules do we need?

Level 1: Read Uncommitted 📖

“See everything, even unfinished work”

• You can see edits someone is STILL making
• Fastest, but messiest
• Like reading over someone’s shoulder while they write

Writer: "The cat sat on the..."
You read: "The cat sat on the..."
Writer: *deletes everything*
You think: "Where did the cat go?!" 😕

Risk: “Dirty reads” - seeing changes that might be undone

Level 2: Read Committed 📗

“Only see finished work”

• You only see changes AFTER they’re saved
• The most common level
• Like only reading published books

Writer: *writing draft...*
You see: Previous published version
Writer: *publishes*
Now you see: New version ✅

Risk: “Non-repeatable reads” - same query, different results

Level 3: Repeatable Read 📘

“Your view stays frozen”

• Once you start reading, the data won’t change
• Like taking a photo of a page
• Others can write, but you see your “snapshot”

You start reading at 10:00 AM
Someone edits at 10:05 AM
You still see the 10:00 AM version ✅

Risk: “Phantom reads” - new rows can appear

Level 4: Serializable 📕

“One at a time, please”

• Strictest level
• Transactions happen one-by-one
• Like locking the whole library for yourself
• Slowest, but safest

Transaction A: Uses entire database alone
Transaction B: Waits...
Transaction A: Done!
Transaction B: Your turn! ✅

Quick Comparison

graph TD
    A["Isolation Levels"] --> B["Read Uncommitted"]
    A --> C["Read Committed"]
    A --> D["Repeatable Read"]
    A --> E["Serializable"]
    B --> F["Fastest ⚡ / Least Safe ⚠️"]
    E --> G["Slowest 🐢 / Most Safe ✅"]

🎁 Wrapping Up: The Transaction Toolbox

🚀 You Did It!

You now understand how databases keep your data safe, even when:

• 🔌 Power goes out
• 🌐 Networks fail
• 👥 Thousands of people act at once

Remember the golden rule: Transactions are promises. They keep ALL their promises, or NONE of them.

💪 You’re ready! These concepts power every bank, every online store, and every app you use. Now you know the magic behind the scenes!