Hands-On SQL & MongoDB Transaction Practice Task

🧪 Practice Task: Managing a Simple Fund Transfer System

---

Practical hands-on practice task for transactions and consistency, designed for both SQL and MongoDB. It reinforces the concepts from Part 10 and helps learners experience the role of transactions in maintaining data integrity.

---

This hands-on task builds on the concepts introduced in Part 10: SQL ACID Transactions vs NoSQL Transactions. We recommend reading it first if you haven’t already.

---

🎯 Objective:

Implement a basic fund transfer between two users and ensure data consistency using transactions in both SQL and MongoDB.

---

⚠️ Prerequisites & Environment Notes:

• Ensure your SQL database (e.g., MySQL with InnoDB or PostgreSQL) supports transactions.
• MongoDB version must be 4.0 or higher. Transactions require running in a replica set, even if it’s a single-node development setup.
• Ensure your accounts collection exists before starting the MongoDB transaction.

---

🔹 Part A: SQL Transaction Practice

🧱 Step 1: Create Tables

CREATE TABLE Accounts (
  AccountID INT PRIMARY KEY,
  Name VARCHAR(100),
  Balance DECIMAL(10, 2)
);

---

🧾 Step 2: Insert Initial Data

INSERT INTO Accounts (AccountID, Name, Balance) VALUES
(1, 'Aisha', 1000.00),
(2, 'Ravi', 500.00);

---

⚙️ Step 3: Write a Transaction

Simulate transferring ₹200 from Aisha to Ravi.

Your task:

• Deduct 200 from Aisha’s account

• Add 200 to Ravi’s account

• Use START TRANSACTION, COMMIT, and ROLLBACK

🔧 Expected Query Structure:

START TRANSACTION;

-- Step 1: Deduct from Aisha
UPDATE Accounts
SET Balance = Balance - 200
WHERE AccountID = 1;

-- Step 2: Add to Ravi
UPDATE Accounts
SET Balance = Balance + 200
WHERE AccountID = 2;

-- Commit if successful
COMMIT;

-- If something fails:
-- ROLLBACK;

---

📤 Expected Output:

Aisha: ₹800.00  
Ravi: ₹700.00

(₹ = Indian Rupees. You can substitute your local currency as needed like $ =Dollar or any other.)

If any part fails (e.g., insufficient balance), rollback should leave both balances unchanged.

---

🔹 Part B: MongoDB Transaction Practice

🧱 Step 1: Insert Accounts

db.accounts.insertMany([
  { _id: 1, name: "Aisha", balance: 1000 },
  { _id: 2, name: "Ravi", balance: 500 }
]);

---

⚙️ Step 2: Simulate a Transaction (Multi-Document)

Use a MongoDB session to transfer ₹200 from Aisha to Ravi.

🔧 Your task:

• Start a session

• Perform two updates inside a transaction

• Handle commit or abort

✅ Code Hint:

const session = db.getMongo().startSession();
session.startTransaction();

try {
  db.accounts.updateOne(
    { _id: 1 },
    { $inc: { balance: -200 } },
    { session }
  );

  db.accounts.updateOne(
    { _id: 2 },
    { $inc: { balance: 200 } },
    { session }
  );

  session.commitTransaction();
  print("Transaction committed.");
} catch (e) {
  session.abortTransaction();
  print("Transaction aborted:", e);
} finally {
  session.endSession();
}

---

📤 Expected Output:

Aisha: 800
Ravi: 700

If anything fails, neither balance should change.

---

💡 Bonus Challenge (Optional)

Enhance your transaction logic by adding a check to ensure the sender (Aisha) has sufficient balance before transferring funds.

• SQL: Add a condition or query to verify Balance >= 200 before proceeding with the deduction.
• MongoDB: Read Aisha’s balance within the session and only proceed if it’s sufficient.

This simulates a real-world scenario where overdrafts are not allowed.

---

🧠 Reflection Questions

1. What happens if you skip the commit in a SQL or MongoDB transaction?

2. Why is it important to use transactions for operations like fund transfers?

3. In MongoDB, what advantages and trade-offs do you notice with session-based transactions?

---

complete solutions to this task will be shared in the next post. Stay tuned! 

← Previous Next →

SQL ACID Transactions vs NoSQL Consistency Explained for Beginners

🔷 Part 10: Transactions and Consistency in SQL vs NoSQL

---

📍 Introduction

Ever wondered what happens if a system crashes in the middle of updating data?

That’s where transactions and consistency come in.

• In SQL, transactions follow ACID rules to keep data safe.

• In NoSQL, the focus shifts to eventual or tunable consistency, especially in distributed environments.

Let’s explore how both systems keep your data reliable — even during failures.

---

🔸 1. What is a Transaction?

A transaction is a group of operations performed as a single unit of work. Either all succeed, or none happen.

💡 Example:

Transferring money between accounts:

• Debit from one account

• Credit to another
  Both must succeed or be rolled back.

---

🔹 2. SQL Transactions & ACID Properties

SQL databases (MySQL, PostgreSQL, etc.) support ACID transactions:

Property	Description
A – Atomicity	All operations complete, or none do
C – Consistency	Data moves from one valid state to another
I – Isolation	Concurrent transactions don’t interfere
D – Durability	Once committed, changes are permanent

---

✅ SQL Example: Bank Transfer

START TRANSACTION;

UPDATE Accounts SET balance = balance - 500 WHERE account_id = 1;
UPDATE Accounts SET balance = balance + 500 WHERE account_id = 2;

COMMIT;

If something fails, use:

ROLLBACK;

📌 Ensures either both updates succeed, or none.

---

🔹 3. NoSQL Transactions and Consistency

Many NoSQL databases like MongoDB, Cassandra, or DynamoDB prioritize speed and availability, often relaxing strict consistency.

✅ MongoDB Transactions

MongoDB (since v4.0) supports multi-document ACID transactions — similar to SQL.

⚠️ Note: MongoDB transactions require a replica set or sharded cluster, even for local development. If you're using a standalone MongoDB instance, transactions won't work.

const session = db.getMongo().startSession();
session.startTransaction();

try {
  db.accounts.updateOne({ _id: 1 }, { $inc: { balance: -500 } }, { session });
  db.accounts.updateOne({ _id: 2 }, { $inc: { balance: 500 } }, { session });

  session.commitTransaction();
} catch (e) {
  session.abortTransaction();
}

---

📦 Eventual vs Strong Consistency

Model	Description
Strong Consistency	Always reads latest write (like SQL)
Eventual Consistency	Reads may return stale data temporarily
Tunable Consistency	Adjustable based on latency, consistency, etc.

Example: In Cassandra, you can choose consistency level per query (QUORUM, ONE, ALL).

This is called tunable consistency. It lets you adjust the trade-off between consistency, latency, and availability.

• ONE: Fastest, but may return stale data.
• QUORUM: Balanced – waits for responses from a majority of replicas.
• ALL: Strongest – waits for all replicas to respond, but slowest.

Choose based on your app's tolerance for stale data vs need for speed.

---

🧠 Comparison Table: SQL vs NoSQL Transactions

Feature	SQL (Relational DBs)	NoSQL (MongoDB, Cassandra, etc.)
Transactions	Built-in ACID	Varies by DB (Mongo supports it)
Consistency Model	Strong	Eventual or Tunable
Rollbacks	Yes	Some support (Mongo, DynamoDB)
Performance	Slower but safer	Faster, more scalable

---

📝 Summary

• SQL ensures strong consistency using ACID rules.

• NoSQL offers flexibility, often sacrificing consistency for speed and scale.

• Some NoSQL databases (like MongoDB, DynamoDB) now support full or partial transactions.

---

✅ What’s Next?

In Part 11, we’ll explore Database Security Basics — covering user roles, authentication, encryption, and common best practices in both SQL and NoSQL systems.

---

• click next forpractice task for transactions

← Previous Next →