DEV Community: aarthirs

MongoDB Indexes Finally Clicked for Me: Understanding Indexes, Compound Indexes & the Prefix Rule 🚀

aarthirs — Wed, 24 Jun 2026 09:34:53 +0000

While working on a MERN project, I came across these indexes:

transactionSchema.index({ user: 1, date: -1 });
transactionSchema.index({ user: 1, type: -1 });
transactionSchema.index({ user: 1, category: -1 });

My first reaction was:

"Why are we creating 3 different indexes for the same schema? Isn't one index enough?"

At that time, my understanding was:

"Indexes help MongoDB find records faster."

Which is true, but it wasn't enough to explain why multiple indexes existed for the same collection.

That simple doubt led me down a rabbit hole of learning about indexes, compound indexes, how MongoDB stores them, and the famous Prefix Rule.

Here's what I learned.

What is an Index?

Imagine a collection with millions of transactions.

db.transactions.find({
  user: "Aarthi"
});

Without an index, MongoDB may need to inspect every document until it finds the matching records.

This is called a Collection Scan.

Think of it like searching for a chapter in a book without a table of contents. You'd have to flip through page after page until you find it.

An index works like a book's table of contents.

Instead of scanning every document, MongoDB can jump directly to the relevant records.

Example:

db.transactions.createIndex({
  user: 1
});

Now MongoDB can quickly locate all transactions belonging to a specific user.

What is a Compound Index?

A compound index contains multiple fields.

Example:

db.transactions.createIndex({
  user: 1,
  date: -1
});

This means MongoDB organizes the index by:

user
  └── date

Conceptually, it looks something like:

Aarthi
   2025-08-10
   2025-08-09
   2025-08-08

John
   2025-08-10
   2025-08-05

The data is first grouped by user, and within each user, it is ordered by date.

Now queries like:

db.transactions.find({
  user: "Aarthi"
}).sort({
  date: -1
});

become very efficient.

MongoDB can jump directly to Aarthi's records and retrieve them in date order.

The Prefix Rule: The Concept That Finally Made It Click

Consider this index:

{
  user: 1,
  date: -1
}

MongoDB can efficiently use it for:

find({
  user: "Aarthi"
});

✅ Works

find({
  user: "Aarthi",
  date: "2025-08-10"
});

✅ Works

But:

find({
  date: "2025-08-10"
});

❌ Not efficient

Why?

Because the index is organized by user first and then by date.

MongoDB knows where each user's records start, but it doesn't know where a specific date begins without first navigating through the user groups.

This behavior is known as the Prefix Rule.

A compound index can efficiently support queries that start from the leftmost fields of the index.

For example:

{
  user: 1,
  date: -1,
  type: 1
}

can efficiently support:

find({ user })

find({ user, date })

find({ user, date, type })

But not:

find({ date })

find({ type })

find({ date, type })

because those queries do not start from the leftmost field.

Back to My Original Doubt

I originally saw:

transactionSchema.index({ user: 1, date: -1 });
transactionSchema.index({ user: 1, type: -1 });
transactionSchema.index({ user: 1, category: -1 });

Now it makes sense.

Recent Transactions

find({ user }).sort({ date: -1 });

Uses:

{ user: 1, date: -1 }

Filter By Transaction Type

find({
  user,
  type: "expense"
});

Uses:

{ user: 1, type: -1 }

Filter By Category

find({
  user,
  category: "food"
});

Uses:

{ user: 1, category: -1 }

Each index is optimized for a different query pattern.

Another Question I Had: Where Are Indexes Stored?

Initially, I thought indexes somehow reorganized the actual documents.

But that's not what happens.

MongoDB stores documents and indexes separately.

Conceptually:

Collection
-----------
Doc1
Doc2
Doc3
Doc4

And separately:

Index(user,date)
----------------
Aarthi -> Doc5
Aarthi -> Doc2
Aarthi -> Doc1

Rosy -> Doc8

Index(user,type)
----------------
Aarthi -> expense -> Doc1
Aarthi -> income  -> Doc2

Rosy -> expense -> Doc8

Index(user,category)
--------------------
Aarthi -> food -> Doc1
Aarthi -> travel -> Doc2

Rosy -> food -> Doc8

The actual documents remain unchanged.

Indexes are separate data structures that contain references to documents.

Then Why Do We Need `.sort()` If the Index Is Already Sorted?

This confused me too.

Suppose we have:

{
  user: 1,
  date: -1
}

The index itself is sorted.

However, MongoDB does not guarantee that results should be returned in date order unless we explicitly request it.

For example:

db.transactions.find({
  user: "Aarthi"
});

This may use the index to locate records quickly.

But:

db.transactions.find({
  user: "Aarthi"
}).sort({
  date: -1
});

tells MongoDB:

"Return these records in descending date order."

Since the index is already sorted that way, MongoDB can use the index directly and avoid an expensive in-memory sort.

That's one of the biggest performance benefits of compound indexes.

How Does MongoDB Handle Multiple Indexes?

This was another question I had.

Suppose we have:

{ user: 1, date: -1 }

{ user: 1, type: 1 }

{ user: 1, category: 1 }

MongoDB creates three completely separate index structures.

Think of them as three separate books:

Index 1

Aarthi
  2025-08-10
  2025-08-09

Rosy
  2025-08-10

Index 2

Aarthi
  expense
  income

Rosy
  expense

Index 3

Aarthi
  food
  travel

Rosy
  shopping

When a query arrives, MongoDB's query planner decides which index can answer the query most efficiently.

Example:

find({
  user: "Aarthi",
  type: "expense"
});

MongoDB sees:

{ user: 1, type: 1 }

and chooses that index.

For:

find({
  user: "Aarthi"
}).sort({
  date: -1
});

MongoDB chooses:

{ user: 1, date: -1 }

because it perfectly matches the query.

Why Not Create One Huge Index?

I also wondered:

{
  user: 1,
  date: -1,
  type: 1,
  category: 1
}

Wouldn't this solve everything?

Not really.

Because of the Prefix Rule.

This index efficiently supports:

find({ user })

find({ user, date })

find({ user, date, type })

But:

find({
  user,
  category
});

is not optimal because date and type appear before category in the index definition.

MongoDB cannot efficiently skip the middle fields.

That's why index design should follow actual query patterns rather than simply including every field.

The Trade-Off Most Beginners Miss

Indexes speed up reads.

But they are not free.

Every insert, update, or delete must also update all related indexes.

For example, when inserting:

{
  user: "Aarthi",
  date: "2025-08-10",
  type: "expense",
  category: "food"
}

MongoDB must update:

Index(user,date)

Index(user,type)

Index(user,category)

every single time.

So indexes improve read performance at the cost of:

Additional storage
Slower writes
Extra maintenance

This is the classic database trade-off.

My Biggest Takeaway

Before this, I thought:

"Indexes make queries faster."

Now I think:

"Indexes make specific query patterns faster."

Understanding compound indexes, how MongoDB stores them, and the Prefix Rule completely changed the way I think about database design.

The best index is not the one with the most fields.

The best index is the one that matches the queries your application runs most often.

Sometimes a simple question like:

"Why do we have 3 indexes for the same schema?"

can lead to understanding an entire database concept.

If you've had a similar "aha!" moment while learning databases, I'd love to hear it in the comments.

JavaScript Promises & Async/Await Explained with a Real-Life Example 🍕

aarthirs — Mon, 15 Jun 2026 16:15:42 +0000

In my previous post, "JavaScript Async Explained Like a Grocery Store 🛒", I covered how the Call Stack, Browser APIs, Event Loop, and Queues work together to handle asynchronous operations.

In this post, we'll answer the next set of questions:

Why do Promises exist?
How does fetch() return data if the API call takes time?
What exactly does .then() do?
Why was async/await introduced?
Does await block JavaScript?

Let's dive in.

The Problem: Waiting Is Expensive

Imagine ordering a pizza online.

After placing the order, would you stand at the door doing absolutely nothing until the delivery arrives?

Probably not.

You would continue:

Watching YouTube
Working
Talking to friends
Doing other tasks

When the pizza arrives, you'll handle it.

JavaScript behaves the same way.

Operations like:

API requests
Database calls
File operations
Timers

can take seconds to complete.

If JavaScript waited for each operation to finish, your application would freeze.

Instead, JavaScript continues executing other code while waiting for the result.

Enter Promises

A Promise represents a value that will be available sometime in the future.

const promise = fetch("/users");

At this moment, the user data isn't available yet.

The Promise is basically saying:

"I don't have the result right now, but I'll let you know when it's ready."

A Promise can be in one of three states:

Pending
   ↓
Fulfilled (Success)

OR

Rejected (Failure)

Where is `new Promise()`?

One question confused me when I first learned Promises.

If Promises are important, why don't I see this everywhere?

new Promise((resolve, reject) => {
  // async work
});

Instead, I often see:

fetch("/users")
  .then(...)

The reason is simple:

Most modern APIs already return Promises for us.

For example:

fetch("/users");

already returns a Promise.

Conceptually, it works something like this:

function fetch(url) {
  return new Promise((resolve, reject) => {

    // Browser performs request

    if (success) {
      resolve(response);
    } else {
      reject(error);
    }

  });
}

The browser creates the Promise.

We simply consume it.

So What Does `.then()` Actually Do?

Consider:

fetch("/users")
  .then(data => {
    console.log(data);
  });

Many beginners think .then() somehow retrieves the data.

That's not really what's happening.

.then() simply registers a callback function.

You're telling JavaScript:

"When this Promise successfully finishes, run this function."

Think of it like a food delivery app.

Order food
      ↓
Food arrives
      ↓
Call me

orderFood().then(eatFood);

The callback doesn't run immediately.

It waits until the Promise resolves.

Promise Chaining

Let's say we need:

User data
User posts
User comments

A common approach is:

fetchUser()
  .then(user => fetchPosts(user.id))
  .then(posts => fetchComments(posts))
  .then(comments => {
    console.log(comments);
  })
  .catch(error => {
    console.log(error);
  });

This works perfectly.

But as applications grow, chains become harder to read and maintain.

Why Async/Await Was Introduced

Async/Await solves the readability problem.

Instead of:

fetchUser()
  .then(user => fetchPosts(user.id))
  .then(posts => {
    console.log(posts);
  });

we can write:

async function getData() {
  const user = await fetchUser();
  const posts = await fetchPosts(user.id);

  console.log(posts);
}

This feels much closer to normal synchronous code.

The logic becomes easier to follow.

Does `await` Block JavaScript?

One of the most common interview questions.

Consider:

async function demo() {
  console.log("A");

  await fetch("/users");

  console.log("B");
}

demo();

console.log("C");

Output:

A
C
B

Many developers initially expect:

A
B
C

But that's not what happens.

When JavaScript reaches:

await fetch("/users");

it pauses only the current async function.

The rest of the application keeps running.

So the flow becomes:

A
Pause async function
C
API finishes
Resume async function
B

This is why await does not block JavaScript.

It only pauses that specific function.

What Happens Under the Hood?

This code:

async function getData() {
  const data = await fetch("/users");
  console.log(data);
}

is roughly equivalent to:

function getData() {
  return fetch("/users")
    .then(data => {
      console.log(data);
    });
}

That's the key idea.

Async/Await is built on top of Promises.

The Promise mechanism still does all the work.

Async/Await simply provides a cleaner syntax.

Mental Models That Help Me Remember

Promise

The food is on the way.

fetch()

Place an online order.
Returns a Promise immediately.

.then()

When the food arrives,
call me.

await

I'll wait here for the food,
but everyone else can continue working.

async function

This function may contain waiting points.

Bonus: Quick Interview Answers !!

What is a Promise?

A Promise is an object representing the eventual success or failure of an asynchronous operation.

What does `.then()` do?

It registers a callback that executes when a Promise resolves successfully.

Why does `fetch()` work with `.then()`?

Because fetch() already returns a Promise.

Does `await` block JavaScript?

No. It pauses only the current async function.

Why was Async/Await introduced?

To make asynchronous code easier to read and maintain compared to Promise chaining.

Async/Await vs Promises?

Async/Await is syntactic sugar built on top of Promises.

Final Takeaway

Whenever I think about asynchronous JavaScript, I remember this:

Promise = Future Value

fetch() = Returns a Promise

.then() = Call me when ready

await = Pause this function, not JavaScript

async/await = Cleaner Promise syntax

Once these five ideas click, Promises and Async/Await become much easier to understand.

# JavaScript Async Explained Like a Grocery Store 🛒

aarthirs — Sat, 13 Jun 2026 07:32:12 +0000

When I first learned JavaScript's Event Loop, I kept reading explanations like:

"Asynchronous tasks are offloaded to Web APIs and their callbacks are placed into the Microtask Queue or Macrotask Queue."

I memorized the words.

But I didn't actually understand what was happening.

Then I started thinking about JavaScript like a grocery store.

JavaScript = One Cashier

Imagine a store with only one cashier.

The cashier can only serve one customer at a time.

That's JavaScript.


`console.log("A");
console.log("B");
console.log("C");`

Output:

A
B
C

Simple. One task after another.

The Problem

Now imagine a customer says:

"Wait 5 seconds before helping the next customer."

If the cashier literally waited 5 seconds, the entire store would stop moving.

That's exactly what would happen if JavaScript handled timers itself.

Browser Web APIs = Helpers

Instead, JavaScript asks a helper:

`setTimeout(() => {
  console.log("Hello");
}, 5000);`

JavaScript says:

"Hey Browser, can you watch this timer for me?"

The browser helper takes the job.

JavaScript immediately continues working.

Start
End

After 5 seconds, the helper comes back and says:

"The timer finished."

Callback Queue = Waiting Line

The browser cannot interrupt JavaScript directly.

So it places the callback into a waiting line.

Browser Helper
      ↓
Callback Queue

The callback waits until JavaScript is free.

Event Loop = Store Manager

The Event Loop is like a manager constantly checking:

Is the cashier busy?

If yes:

Wait

If no:

Take the next customer from the waiting line

That's all the Event Loop does.

Why Does Promise Run Before setTimeout?

`console.log("Start");

setTimeout(() => {
  console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise");
});

console.log("End");`

Output:

Start
End
Promise
Timeout

Because JavaScript has two waiting lines:

High Priority Line

Promise.then()
queueMicrotask()

Normal Line

setTimeout()
setInterval()
DOM events

The Event Loop always clears the high-priority line first.

That's why Promise executes before setTimeout.

What About fetch()?

`fetch("/users")
  .then(res => res.json())
  .then(data => console.log(data));`

The browser handles the network request.

JavaScript doesn't sit around waiting for the server.

Once the response arrives, the callback gets added to the queue and runs when JavaScript is ready.

Why Do Web Workers Exist?

Imagine the cashier receives a task that takes 10 minutes.

Nobody else gets served.

The store freezes.

That's what happens when JavaScript performs heavy calculations on the main thread.

Web Workers solve this by hiring another cashier.

Heavy work runs on a separate thread while the main UI remains responsive.

Final Mental Model

Whenever you see async JavaScript:

JavaScript = Cashier

Browser Web APIs = Helpers

Callback Queue = Waiting Line

Event Loop = Manager

Web Workers = Extra Cashiers

Once this model clicks, the Event Loop becomes much easier to understand than memorizing definitions.

# The Turing Dial: A Solstice Cryptography Protocol

aarthirs — Sun, 07 Jun 2026 15:19:26 +0000

This is a submission for the June Solstice Game Jam

How It Works (The Theme Connection)
The game maps the physical passage of time during the Solstice to computational logic constraints. As the game clock cycles from day to night, your processing framework degrades across three environmental phases:

Sunrise (Unary): Pure binary processing.
High Noon (Boolean): Advanced algebraic logic gates (AND, OR, NOT).
Midnight (Enigma): Hard cryptographic bit-parity challenges that honor Turing's codebreaking at Bletchley Park.

Behind the Curtain: Best Google AI Usage

Instead of using the Gemini API as a simple chat box, Gemini 2.5 Flash acts as our automated Procedural Level Designer.

Every time the environment transitions, the system fires a background request to Google AI Studio. Gemini dynamically parses the current game state and feeds back:

A unique, context-aware matrix puzzle directive (puzzleHint).
The dynamic numeric or parity solution ruleset (solutionKey).
A curated, inspiring quote reflecting Alan Turing's legacy, Juneteenth, or Pride Month (historyQuote).

If the network connection ever fails, a native hardware fallback loop steps in to ensure seamless offline gameplay.

Built With

Pure HTML5 / CSS Grid (with a custom CRT scanline terminal effect)
Modular Vanilla JavaScript
Official @google/genai SDK via CDN

Play the Game

GitHub Repository: github
Live Demo:vid demo

DEV Community: aarthirs

MongoDB Indexes Finally Clicked for Me: Understanding Indexes, Compound Indexes & the Prefix Rule 🚀

What is an Index?

What is a Compound Index?

The Prefix Rule: The Concept That Finally Made It Click

Back to My Original Doubt

Recent Transactions

Filter By Transaction Type

Filter By Category

Another Question I Had: Where Are Indexes Stored?

Then Why Do We Need .sort() If the Index Is Already Sorted?

How Does MongoDB Handle Multiple Indexes?

Index 1

Index 2

Index 3

Why Not Create One Huge Index?

The Trade-Off Most Beginners Miss

My Biggest Takeaway

JavaScript Promises & Async/Await Explained with a Real-Life Example 🍕

The Problem: Waiting Is Expensive

Enter Promises

Where is new Promise()?

So What Does .then() Actually Do?

Promise Chaining

Why Async/Await Was Introduced

Does await Block JavaScript?

What Happens Under the Hood?

Mental Models That Help Me Remember

Promise

fetch()

.then()

await

async function

Bonus: Quick Interview Answers !!

What is a Promise?

What does .then() do?

Why does fetch() work with .then()?

Does await block JavaScript?

Why was Async/Await introduced?

Async/Await vs Promises?

Final Takeaway

# JavaScript Async Explained Like a Grocery Store 🛒

JavaScript = One Cashier

The Problem

Browser Web APIs = Helpers

Callback Queue = Waiting Line

Event Loop = Store Manager

Why Does Promise Run Before setTimeout?

High Priority Line

Normal Line

What About fetch()?

Why Do Web Workers Exist?

Final Mental Model

# The Turing Dial: A Solstice Cryptography Protocol

Behind the Curtain: Best Google AI Usage

Built With

Play the Game

Then Why Do We Need `.sort()` If the Index Is Already Sorted?

Where is `new Promise()`?

So What Does `.then()` Actually Do?

Does `await` Block JavaScript?

What does `.then()` do?

Why does `fetch()` work with `.then()`?

Does `await` block JavaScript?