But let's be real. That assumption is wildly outdated.

Scaling horizontally doesn't mean you have to sacrifice data integrity. I was recently digging through some architectural docs and realized how many developers still don't know that MongoDB has supported robust, multi-document ACID transactions for years.

Let's break down exactly what ACID means in the real world, how it evolved, and how MongoDB manages to deliver strict data guarantees without losing its NoSQL flexibility.

(Note: A lot of the foundational architecture in this post is based on MongoDB's official guide to ACID transactions, which is a fantastic resource if you want to go deeper).

A Quick History Lesson: Where Did ACID Come From?

Before we talk about modern document databases, we need to look back at the late 1970s and early 1980s. As businesses started relying on digital records for banking and telecommunications, they needed absolute guarantees that their data wouldn't corrupt if a server crashed mid-operation.

In 1983, computer scientists Andreas Reuter and Theo Härder formally defined the four ACID properties. This framework became the undisputed gold standard for relational database management systems (RDBMS) like Oracle, IBM DB2, and eventually PostgreSQL.

When NoSQL databases rose to popularity in the 2010s to handle massive, unstructured datasets, early versions did relax consistency in favor of raw performance. That created the myth that NoSQL and ACID were mutually exclusive. But as distributed systems evolved, vendors like MongoDB figured out how to engineer multi-document transactions across distributed nodes.

What is ACID, Exactly? (And How MongoDB Handles It)

ACID stands for Atomicity, Consistency, Isolation, and Durability. Together, they ensure that a transaction - a grouped set of read/write operations - leaves your database in a valid state even if everything catches on fire.

Here is how a document database handles the classic RDBMS rules:

1. Atomicity: The "All or Nothing" Rule

Atomicity guarantees that if a transaction fails halfway through, the entire thing is rolled back. If a user is paying for a premium subscription in your app, the database needs to debit their account and upgrade their user role. If the role upgrade fails, the money shouldn't be deducted.

The MongoDB Way: Because MongoDB is a document database, a write operation is atomic at the document level. If you embed arrays and sub-documents directly inside a single user document, updating all that nested data is fully atomic by default. For the rare cases where you absolutely must update multiple separate collections simultaneously, MongoDB supports distributed multi-document transactions across replica sets and sharded clusters.

2. Consistency: Obeying the Laws of the Schema

Consistency ensures that any transaction brings the database from one valid state to another, strictly adhering to defined rules and constraints.

The MongoDB Way: MongoDB gives you flexibility in how you achieve this. If you have related data, you can:

• Use Transactions: Updates to multiple collections occur in one atomic operation. You get perfect consistency, but it can impact performance if there's heavy read contention.

• Embed Related Data: Just shove the related data into a single document. This is highly performant and keeps everything consistent without complex joins.

• Use Atlas Database Triggers: Update one collection, and let a background trigger update the other. Great for performance, but you have to be okay with eventual consistency (users might see slightly stale data for a few milliseconds).

3. Isolation: Staying in Your Lane

Isolation prevents concurrent transactions from interfering with each other. If two users try to book the exact same movie seat at the exact same millisecond, the database shouldn't crash or double-book.

The MongoDB Way: MongoDB uses a technique called snapshot isolation. When a transaction starts, it takes a private, virtual snapshot of the database. The transaction operates on this isolated view. If it tries to commit and the lock manager detects that another operation has modified the same data in the meantime, the transaction is safely aborted to prevent a conflict.

4. Durability: Written in Stone

Durability means that once a transaction says "committed," it's permanent. Even if someone trips over the server's power cord a microsecond later, that data will be there when the machine boots back up.

The MongoDB Way: MongoDB achieves this through a combination of write-ahead logging (the journal) and distributed replica sets. Before a change is finalized, it's written to an on-disk journal. Furthermore, you can configure your write concerns so that a transaction isn't considered "complete" until it has successfully replicated to a majority of your backup nodes.

When Should You Actually Use Distributed Transactions?

Just because you can use multi-document transactions in MongoDB doesn't mean you always should.

If you are coming from a traditional SQL background (like PostgreSQL or MySQL), your instinct is usually to normalize everything into separate tables and use transactions to tie them together.

In MongoDB, 80% to 90% of your transactional needs can be solved by simply designing a better schema. Because documents can contain rich, hierarchical data structures, you can often keep related data together.

Reserve multi-document transactions for the edge cases:

1. Financial Ledgers: Transferring balances between two isolated account documents.

2. Complex Inventory Systems: Deducting stock from a central inventory collection while simultaneously creating a detailed order in an orders collection.

3. Strict Regulatory Compliance: When the law dictates that multi-system data must be perfectly synced with zero tolerance for eventual consistency.

The Takeaway

The database landscape isn't black and white anymore. You don't have to choose between the developer-friendly flexibility of document schemas and the iron-clad safety of ACID compliance. If you structure your data correctly, you get atomicity out of the box. And when you need to bring out the big guns for multi-collection transactions, the architecture is already there waiting for you.

For a deeper dive into the specific lock mechanisms and performance impacts, check out the original MongoDB resource on ACID transactions.

Enter Promises.

Today, we are going to break down Promises using the most painfully relatable Indian contexts.

In JavaScript, a Promise is an object representing the eventual completion (or failure) of an asynchronous operation and its resulting value.

Think of it like one of the below...

🔸 A placeholder for a value that will arrive in the future

🔸 A container for a future value

🔸 A wrapper around an async result

A Promise is always in one of these three states:

• 🟡 Pending: The initial state. The outcome is unknown.

• 🟢 Fulfilled: The operation completed successfully.

• 🔴 Rejected: The operation failed.

The Real-Life Definitions

The "friend" Example: Imagine your Dost/Friend says: "Bhai kal pakka ₹5000 bhej raha hoon." That is a Promise.

• 😅 Pending → Kal aayega...

• 👌 Fulfilled → ₹5000 received in your bank account!

• 🏃 Rejected → "Broo iss mahine thoda tight hai..."

How to Create a New Promise:

You create a custom Promise using the new Promise() constructor but 95% of real-world work uses consuming, not building. It takes one parameter: a callback function (often called the executor).

This executor function itself takes two parameters:

1. resolve: A function you call when your asynchronous task completes successfully.

2. reject: A function you call when your task fails.

const myPromise = new Promise((resolve, reject) => {
  let isSuccessful = true; // Setting a condition

  if (isSuccessful) {
    resolve("Yay! It worked!"); // Transitions state to Fulfilled
  } else {
    reject("Oops! Something went wrong."); // Transitions state to Rejected
  }
});

Handling Promises:

Once a Promise settles, you need to handle the outcome. Here is how we do it, desi style.

.then() - Handle Success

• Runs when the Promise is Fulfilled.

  • Example: 💝If crush replies → smile automatically.

.catch() - Handle Failure

• Runs when the Promise is Rejected.

  • Example: 💔If crush leaves on seen → buy gym membership.

.finally() - Always Runs

• Runs regardless of success or failure. The ultimate truth.

  • Example: 💥Result kuch bhi ho… drama toh hoga.

Example:

const textCrush = new Promise((resolve, reject) => {
  const crushMood = Math.random() > 0.5;

  setTimeout(() => {
    if (crushMood) {
      resolve("Crush replied: 'Hey 😊'");
    } else {
      reject("Crush left you on seen 💀");
    }
  }, 1000);
});

textCrush
  .then(message => {
    console.log(message);
    console.log("💝smiling at phone like idiot / Phas gaya aa 😌");
  })
  .catch(error => {
    console.log(error);
    console.log("💔Opening gym membership website 🏋️‍♂️");
  })
  .finally(() => {
    console.log("💥Result kuch bhi ho… drama toh hoga.");
  });

/*
Console Output (after 1 second):

IF RESOLVED:
Crush replied: 'Hey 😊'
💝smiling at phone like idiot / Phas gaya aa 😌
💥Result kuch bhi ho… drama toh hoga.

--------------------------------------------

IF REJECTED:
Crush left you on seen 💀
💔Opening gym membership website 🏋️‍♂️
💥Result kuch bhi ho… drama toh hoga.
*/

Instant Gratification & Disappointment

Sometimes you don't need to wait.

Promise.resolve() (Immediate Success)

• Example: Mom: "Khane mein kya hai?" Mom herself: "Rajma Chawal bana diya." Instant happiness.

• const checkDinner = Promise.resolve("Rajma Chawal ready 🍛");
  
  checkDinner.then(msg => console.log("Mood upgraded 😌:", msg));
  

Promise.reject() (Immediate Disappointment)

• Example: Asking Friend for Money

• const askFriend = Promise.reject("Bhai khud broke hoon 💸");
  
  askFriend.catch(err => console.log("Survival mode activated 🫠:", err));
  

Advanced Promise Methods: The Multi-Taskers

Promise.all() - Parallel, Fails Fast

• Rule: All must succeed, or the whole thing fails.

• Example (Shaadi Plan): 💃Caterer booked. Band booked. Marriage hall booked. If the pandit cancels → entire wedding is in chaos!

• const caterer = Promise.resolve("Caterer ready 🍛");
  const band = Promise.resolve("Band ready 🥁");
  const pandit = Promise.reject("Pandit cancelled ❌");
  
  Promise.all([caterer, band, pandit])
    .then(res => console.log("Shaadi ON 🎉", res))
    .catch(err => console.log("Shaadi Cancelled 💀:", err));
  

Promise.allSettled() - Waits for all, never fails

• Rule: I want the full report. Drama included. I don't care if some failed.

• Example (Rishta Hunting): 👰‍♀️Rishta 1 → rejected. Rishta 2 → ghosted. Rishta 3 → interested. You still want the full status report from the matchmaker.

• const rishta1 = Promise.reject("Rejected ❌");
  const rishta2 = Promise.reject("Ghosted 👻");
  const rishta3 = Promise.resolve("Interested 😊");
  
  Promise.allSettled([rishta1, rishta2, rishta3])
    .then(report => console.log("Full Rishta Report 📋:", report));
  

Promise.race() - First settled wins (Good or Bad)

• Rule: First to finish wins, whether it's a resolve or reject.

• Example (Swiggy vs Zomato): 📦Order from both. Whichever delivers first gets the tip.

• const swiggy = new Promise(res => setTimeout(() => res("Swiggy Delivered 🚴"), 2000));
  const zomato = new Promise(res => setTimeout(() => res("Zomato Delivered 🛵"), 1000));
  
  Promise.race([swiggy, zomato])
    .then(winner => console.log("Food from:", winner));
  

Promise.any() - First fulfilled wins

• Rule: First success wins. Ignore the failures.

• Example (Marriage Proposal Attempt): 😉Ask 3 people out. First "yes" wins. The others? Ignored 😌.

• const crush1 = Promise.reject("No ❌");
  const crush2 = Promise.reject("Already committed 💔");
  const crush3 = Promise.resolve("Yes 😊");
  
  Promise.any([crush1, crush2, crush3])
    .then(success => console.log("Success:", success))
    .catch(() => console.log("All rejected 😭"));
  

The TL;DR: Your Desi Cheat Sheet

Next time you are writing asynchronous JavaScript and start feeling lost, just close your eyes, take a deep breath, and remember these golden rules of Indian life:

• A Promise is just your Chacha owing you money. It’s Pending until it’s either in your bank (Fulfilled) or he makes a solid excuse (Rejected).

• .then(), .catch(), and .finally() is the ultimate cycle of life: Hoping for the best, dealing with the heartbreak, and still having to eat dinner with your annoying siblings anyway.

• Promise.all() = The Shaadi Plan. If even one vendor cancels, the whole wedding is ruined.

• Promise.allSettled() = The Rishta Report. You want all the tea and gossip, whether they said yes, no, or totally ghosted.

• Promise.race() = Mom vs. Alarm Clock. Whoever triggers first, wins your attention.

• Promise.any() = Begging for notes at 11:59 PM. The very first person to send the PDF is literally God; the rest are ignored.

Master these mental models, and you will never fear async code or Promises again. Your JavaScript fundamentals will be as solid and guaranteed as a mother's Promise.resolve("Rajma Chawal").