Building Transactions: A Preview

How Do Databases Handle Concurrent Requests?

Picture a bustling restaurant. Ten friends, ten simultaneous orders. Each order is a sequence: check ingredients, cook, plate, serve. The kitchen must juggle these demands, ensuring each diner gets exactly what they asked for.

The Kitchen Analogy

Busy restaurant kitchen with multiple orders

The Challenge: 10 Orders at Once

Option 1: One Order at a Time (Serial)

Complete Isolation (The DMV Approach)

Think DMV: orderly, foolproof, and excruciatingly slow.

Process:

  • Take Order #1 → Prepare completely → Serve
  • Take Order #2 → Prepare completely → Serve
  • Repeat until all 10 orders are done
✅ Pros
  • No mix-ups
  • Simple management
  • Guaranteed accuracy
❌ Cons
  • Incredibly slow
  • Idle kitchen staff
  • Unnecessary customer wait times

Option 2: Smart Interleaving (Concurrent)

Optimized Efficiency (The Busy Bar Approach)

Like a Friday night bar: chaotic in appearance, but the bartender keeps track, and drinks are served swiftly.

Process:

  • Start drinks for all orders (quick step)
  • Fry multiple orders of fries
  • Grill burgers while fries cook
  • Assemble orders as components finish
✅ Pros
  • Faster overall
  • Resource-efficient
  • Improved customer experience
⚠ Challenges
  • Potential for order mix-ups
  • Requires complex coordination
  • Demands precise tracking

The Key Insight: Isolation Guarantee

Each Customer's Expectation

No matter how chaotic the kitchen, each customer must receive their complete, correct order — as if they were the only one being served.

✅ Good Isolation

Alice orders a burger and fries. She gets her order precisely, even as the kitchen juggles drinks for five others while her fries cook.

❌ Broken Isolation

Alice's fries end up with Bob. Alice is missing fries, and Bob has extras he didn't order.

The Database Version: Transaction Manager

nanoDB transaction processing overview

The Three Types of Schedules

Serial Schedule 1

Finish Transaction 1, then Transaction 2, then Transaction 3...

T1: ████
T2: ████
T3: ████

Safe but slow

Serial Schedule 2

Different order: Transaction 2, then Transaction 1, then Transaction 3...

T2: ████
T1: ████
T3: ████

Also safe but slow

Interleaved Schedule

Mix operations from different transactions smartly

T1: █ T2: ██ T1: █ T3: ██ T1: ██ T2: ██

Fast if done correctly

What's Coming Next?

The Journey Ahead

1

Foundation

ACID Properties

The four guarantees every transaction needs: Atomicity, Consistency, Isolation, Durability

"What promises do we make to users?"

2

Concurrency Control

Isolation in Practice

How to allow interleaving without breaking isolation: Locks, Timestamps, Snapshot Isolation

"How do we coordinate multiple transactions?"

3

Recovery

When Things Go Wrong

How to guarantee durability even when systems crash: Write-Ahead Logging, Checkpointing

"How do we survive failures?"

4

Distributed Transactions

Multiple Databases

Coordinating transactions across multiple systems: Two-Phase Commit, Consensus

"What about multiple restaurants in a chain?"

The Challenge Ahead

The Million-Dollar Question

How can we be ultra-fast while maintaining perfect correctness?

This is what transaction processing is all about.