DEV Community: Vijay Rangan

The Bug Behind Double Bookings

Vijay Rangan — Sat, 24 Oct 2026 13:30:00 +0000

Here's a booking function. It checks whether the room is free for the night, and if it is, it saves the booking.

async function book(roomId: string, night: string, guest: string) {
  const { rows } = await pool.query(
    "SELECT count(*)::int AS taken FROM bookings WHERE room_id = $1 AND night = $2",
    [roomId, night],
  );
  if (rows[0].taken > 0) return `${guest}: sorry, already booked`;

  await pool.query(
    "INSERT INTO bookings (room_id, night, guest) VALUES ($1, $2, $3)",
    [roomId, night, guest],
  );
  return `${guest}: confirmed`;
}

Every line is correct. It passes the tests you'd write for it. And if ten guests try to book the same room for the same night at the same moment, all ten are confirmed.

The bug isn't in any single line. It's in the gap between two of them. It's called a race condition, and this post covers why it happens, why your tests miss it, and three ways to fix it in Postgres.

What it costs

To the business, a double booking isn't a stack trace. It's a guest turned away at check-in, a refund, a support ticket and a bad review. It shows up on your busiest nights, because that's when requests overlap. The same bug sells one seat twice, applies one coupon twice, or takes an account below zero.

The tables

The examples use two tables:

CREATE TABLE rooms (
  id text PRIMARY KEY,
  name text NOT NULL
);

CREATE TABLE bookings (
  id bigserial PRIMARY KEY,
  room_id text NOT NULL REFERENCES rooms (id),
  night date NOT NULL,
  guest text NOT NULL,
  guests int NOT NULL DEFAULT 1
);

Concurrency, not parallelism

Two words get mixed up here. Concurrency means several tasks are in progress at once and take turns. Parallelism means several tasks are running at literally the same instant, on different cores or machines.

You don't need parallelism to get this bug. Each await is a point where one request pauses and another can run. So even one Node.js process on one core can interleave two bookings like this:

In production it's worse: you run several servers behind a load balancer, and requests really do arrive together.

The shape to look for: check, then act

This bug has a name: a race condition. Two requests race through the same check, and both win.

The general shape is check-then-act: read something, decide, then write based on what you read. Between the read and the write there's a gap. If anything changes the data inside that gap, the decision was based on stale information.

Once you know the shape, you'll see it everywhere:

"If this email isn't registered, create the account."
"If the balance covers it, deduct the amount."
"If seats are left, sell one."
"If the coupon hasn't been used, apply it."

Why your tests don't catch it

A test usually makes one request, waits for it, then checks the result. Nothing ever competes for the gap, so the race never happens.

To see it, make the requests overlap on purpose, against a real database. One detail matters more than you'd expect: warm up the connection pool first. Run against a fresh pool, opening the connections spaces the requests out, and only one booking gets through. With the pool warmed up, all ten are confirmed. In ten runs of each against Postgres 17, that held every time.

const guests = ["Asha", "Ravi", "Meera", "Karan", "Priya", "Arjun", "Neha", "Vikram", "Divya", "Rohan"];

// Open the connections first, so the bookings really overlap.
await Promise.all(guests.map(() => pool.query("SELECT 1")));

const results = await Promise.all(guests.map((guest) => book("room_101", "2026-12-31", guest)));
console.log(results); // ten "confirmed", one room

Keep a test like this for every write path where duplicates would hurt. And note what the cold pool shows: a race that depends on timing can pass your tests and still happen in production.

Fix 1: let the database say no

If the rule can be written as "this must be unique", stop checking in application code and let the database enforce it. Postgres checks and saves in one step, so there's no gap left:

ALTER TABLE bookings
  ADD CONSTRAINT one_booking_per_night UNIQUE (room_id, night);

Then just try the insert, and treat a unique violation as "already taken". Postgres reports it with error code 23505 (unique_violation):

async function book(roomId: string, night: string, guest: string) {
  try {
    await pool.query(
      "INSERT INTO bookings (room_id, night, guest) VALUES ($1, $2, $3)",
      [roomId, night, guest],
    );
    return `${guest}: confirmed`;
  } catch (err) {
    if ((err as { code?: string }).code === "23505") return `${guest}: sorry, just taken`;
    throw err;
  }
}

Run the ten-guest test again: one confirmation, nine "sorry, just taken", one row saved.

Two things worth knowing:

You can skip the error entirely. ON CONFLICT DO NOTHING turns the clash into "no row inserted", which you check without a try/catch:

const { rowCount } = await pool.query(
  `INSERT INTO bookings (room_id, night, guest) VALUES ($1, $2, $3)
   ON CONFLICT (room_id, night) DO NOTHING`,
  [roomId, night, guest],
);
return rowCount === 1 ? `${guest}: confirmed` : `${guest}: sorry, just taken`;

Inside a transaction, the error ends the transaction. If the insert runs between BEGIN and COMMIT, a 23505 aborts the whole transaction. Every statement after it fails with 25P02 until you roll back. So catch it, roll back, then answer the guest. ON CONFLICT DO NOTHING avoids this, because nothing fails.

This is the simplest fix, so start here whenever the rule fits.

Fix 2: lock the row

Not every rule can be written as "unique". Say the villa can host two small groups a night, but not three. That rule replaces fix 1, so there's no unique constraint on (room_id, night) here. A unique constraint can't count, so you're back to read, decide, save.

This time you make sure nobody else does the same at the same moment, by locking a row inside a transaction with SELECT … FOR UPDATE:

async function book(roomId: string, night: string, guest: string) {
  const client = await pool.connect();
  try {
    await client.query("BEGIN");
    await client.query("SELECT id FROM rooms WHERE id = $1 FOR UPDATE", [roomId]);

    const { rows } = await client.query(
      "SELECT count(*)::int AS groups FROM bookings WHERE room_id = $1 AND night = $2",
      [roomId, night],
    );
    if (rows[0].groups >= 2) {
      await client.query("ROLLBACK");
      return `${guest}: sorry, already booked`;
    }

    await client.query(
      "INSERT INTO bookings (room_id, night, guest) VALUES ($1, $2, $3)",
      [roomId, night, guest],
    );
    await client.query("COMMIT");
    return `${guest}: confirmed`;
  } catch (err) {
    await client.query("ROLLBACK");
    throw err;
  } finally {
    client.release();
  }
}

Notice which row is locked: the room, not a booking. You can't lock a booking that doesn't exist yet. So you lock the parent row that every booking for that room has to go through.

When Ravi's request reaches the FOR UPDATE, it waits until Asha's transaction commits. Then its count sees her booking. That last step depends on Postgres's default isolation level, READ COMMITTED, where each statement sees the latest committed data. At REPEATABLE READ, the count still sees the database as it was when the transaction started. Run the same code at that level with ten guests and all ten get booked.

This works for almost any rule, but it has costs:

Everyone waits in line. All bookings for that room queue behind the lock, so on a busy night requests pile up.
Deadlocks. If one request locks room A then room B, and another locks B then A, each waits for the other forever. Postgres detects this and cancels one of them with error 40P01. Lock rows in a consistent order, for example by id, to avoid it.
Keep the lock short. Never charge a card or call another service while holding it. Everyone else is stuck waiting on you.

Fix 3: check nothing changed (optimistic locking)

The same race happens with edits. Two staff members open Asha's booking at once. Meera changes it to two guests, Karan to four. Whoever saves last wins, and the other change disappears without an error. Nobody knows.

The fix is a version number. Remember the version when you read, and only update if it's still the same:

ALTER TABLE bookings ADD COLUMN version int NOT NULL DEFAULT 1;

async function changeGuests(bookingId: number, guests: number, versionRead: number) {
  const { rowCount } = await pool.query(
    "UPDATE bookings SET guests = $1, version = version + 1 WHERE id = $2 AND version = $3",
    [guests, bookingId, versionRead],
  );
  if (rowCount === 0) return "This booking just changed. Reload and try again.";
  return "Saved";
}

Meera saves first and the version moves to 2. Karan's update looks for version 1, matches nothing and changes 0 rows, so he's asked to reload. Nobody waits, and no change is lost silently.

The catch: whoever loses has to redo their work. That's fine when clashes are rare. If many people edit the same thing at once, they keep losing and retrying, and a lock (fix 2) is the better choice.

What about SERIALIZABLE?

Postgres's strictest isolation level catches this race on its own, with no lock and no constraint. Run the original check-then-insert inside a SERIALIZABLE transaction and Postgres lets one booking through. The others fail with error 40001 (serialization_failure). The catch: your code has to retry every transaction that fails that way. Isolation levels get their own video later in this series.

Which fix to use

Can the rule be written as "this must be unique"? Use a unique constraint.
Do you need to read, decide, then save? Lock the row, as long as traffic on that row isn't too high.
Is it an edit that rarely clashes? Use a version column.

When bookings span several nights

A unique constraint on (room_id, night) works when you store one row per night. If you store a stay as a date range instead, Postgres has exclusion constraints, which refuse any row that overlaps an existing one:

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE stays (
  id bigserial PRIMARY KEY,
  room_id text NOT NULL,
  stay daterange NOT NULL,
  EXCLUDE USING gist (room_id WITH =, stay WITH &&)
);

Two stays for the same room (=) whose ranges overlap (&&) can't both exist. The losing insert fails with error 23P01 (exclusion_violation), which you handle the same way as 23505. Back-to-back stays are fine, because a range like [2026-12-30, 2027-01-02) ends before the next one starts.

Retries: the same request, twice

There's one more way to get a duplicate, and no other guest is involved. A client times out and retries, a queue redelivers a message, or a background job runs again, and the same booking request arrives twice.

The fix is an idempotency key: a unique id the client generates once per booking attempt and sends with every retry. Store it under a unique constraint, and a repeat returns the first result instead of booking again:

ALTER TABLE bookings ADD COLUMN request_id uuid UNIQUE;

async function book(roomId: string, night: string, guest: string, requestId: string) {
  const inserted = await pool.query(
    `INSERT INTO bookings (room_id, night, guest, request_id) VALUES ($1, $2, $3, $4)
     ON CONFLICT DO NOTHING
     RETURNING id`,
    [roomId, night, guest, requestId],
  );
  if (inserted.rowCount === 1) return `${guest}: confirmed`;

  // Nothing inserted: either this request was seen before, or the room is taken.
  const { rows } = await pool.query("SELECT guest FROM bookings WHERE request_id = $1", [requestId]);
  if (rows.length === 1) return `${rows[0].guest}: confirmed`;
  return `${guest}: sorry, just taken`;
}

The ON CONFLICT has no target on purpose. With fix 1's unique constraint also in place, a repeated request clashes with both constraints. With ON CONFLICT (request_id), retries arriving at the same moment fail with 23505 from the other constraint. Without a target, any clash means "nothing inserted", and the lookup tells the two cases apart.

AI agents, background jobs and workers act on the same records your users do, often in parallel and often with retries. Every fix here applies to them too.

Start with the database

Most check-then-act code can be replaced by a rule the database enforces: a unique constraint, an exclusion constraint, a conditional update. Reach for a lock only when the rule can't be written that way, and test with requests that really overlap.

I built this example and ran all three fixes with ten guests in the video:

Originally published on the Tech Swamy blog. If your startup is growing fast and bugs like this are starting to show up (double bookings, lost updates, things that only break on your busiest days), that's the work we do at Tech Swamy.

The Rewrite We Didn't Do

Vijay Rangan — Fri, 23 Oct 2026 13:30:00 +0000

The upgrade was MongoDB 5.0.17 to 5.0.18: a patch release, the kind you approve without a second look. After it, a recalculation in one customer's environment was taking about two days to finish.

When something breaks that badly, the room fills with big ideas. Maybe the computation engine has reached its limits. Maybe the database needs rethinking. Maybe this is finally the moment for the big rewrite the team had been discussing. Two days feels like a fundamental problem, so it seems to deserve a fundamental fix.

We didn't rewrite anything. The fix turned out to be much smaller, and finding it taught us more than the fix did.

A platform that was already slowing down

The client runs a carbon accounting platform. Enterprise customers bring in their business data, the platform matches that activity to emissions information, and a computation engine calculates their footprint. Customers change an assumption, recalculate and explore the result, so speed isn't a nice-to-have. It's how the product gets used.

By the time I joined, embedded with their engineering team, that loop was getting slow. Change a parameter and you waited minutes. Competitors were offering faster experiences, and the database bill kept climbing, because one way the team had kept up was by moving to bigger instances.

You've probably seen that pattern. Things slow down, someone bumps the instance size, it gets a bit better, and a few months later you're back where you started, paying more for it. Bigger hardware hides a problem without telling you what it is. So when the two-day recalculation arrived, nobody could say where the time was going.

Finding where the time went

There was no end-to-end view of what happened after a customer pressed recalculate. So we built one by hand. We traced requests from the API downwards, matched log lines across services by their correlation IDs, followed the query path into the database, and sat with the engineers who owned each stage of the pipeline to piece the run together.

It was slow, careful work, and it kept narrowing the question. Not "why is the system slow?" but "which step is slow?", then "which queries in that step?", then "what is the database actually doing with them?". At that last level the questions are concrete: is each query using an index or reading the whole collection, and how many documents does it examine for every one it returns?

// Illustrative, not the client's query or schema
db.activities
  .find({ orgId: orgId, period: { $gte: from, $lt: to } })
  .explain("executionStats")

// What to read in the result:
//   winningPlan: IXSCAN (uses an index) or COLLSCAN (reads everything)
//   totalDocsExamined compared with nReturned

The answer was indexes. Some needed rebuilding, and once they were back in place, the same recalculation came down from about two days to about 15 minutes. Other environments saw similar improvements.

I'll be honest about the gap in this story: we never fully pinned down why the upgrade caused it, and I'm not going to guess. What we do know is what fixed it, and how close we came to fixing the wrong thing. If we had trusted the size of the symptom, we could have spent months rebuilding an engine that didn't need rebuilding.

The real fix was the next investigation

Rebuilding the indexes took far less time than finding out that indexes were the problem. That was the part worth fixing.

So we gave the platform the visibility it had been missing. We built an observability layer on OpenTelemetry, chosen so the services weren't tied to any one vendor's monitoring code, with a collector running alongside the services and the signals flowing into the company's existing AWS stack: logs and metrics in CloudWatch, traces in X-Ray, and Grafana dashboards on top.

The tooling wasn't the important decision, though. Adoption was. If instrumenting a service is a project, teams put it off, and the next incident starts from zero again. So we wrapped the setup in a small shared TypeScript library, common-observability, that gave a service traces and metrics with about one line of code:

// Illustrative
import { initObservability } from "@company/common-observability";

initObservability({ serviceName: "calculation-engine" });

After that, the conversation about performance changed. "The system is slow" became "this step dominates the request, and here's the query behind it." The next investigation would start with evidence, not detective work.

A second question: does the data model still fit?

While we were looking closely at how the application used MongoDB, we found something separate from the regression, and it's the part most likely to apply to your system too.

Many of the access patterns were relational. Collections were joined with $lookup again and again across large workloads, and data was duplicated where it didn't need to be. We moved towards read-optimised collections, shaped around the questions the application actually asks, and precomputed results where the workload justified it.

To be clear, $lookup didn't cause the regression, and this isn't a story against MongoDB, which was a perfectly reasonable choice. The problem was the fit between the data model and the way the product had come to be used. That fit drifts as a product grows, and nobody notices until something forces a closer look.

Before you approve a rewrite

Sometimes the rewrite, or the new database, really is the answer. But it should be the conclusion of an investigation, not the response to a symptom. Before you commit to one, I'd want these answered:

Can you name the step that's slow, and show the trace? If not, you're sizing a fix for a problem you haven't found.
What changed just before it got worse? Deploys, upgrades, data growth, a new customer's data. Check the boring changes first, patch releases included.
Have you read the query plans for the hot paths? Index use, and documents examined against documents returned.
Is bigger hardware hiding the problem? If the instance size only ever goes up, you're paying for the problem instead of fixing it.
Is the case for the big change written down? A proposal engineers can push back on, and a time-boxed proof of concept before the commitment. On this engagement, engineers did push back, and the decisions were better for it.

The better first move is almost always the same: make the work visible, find the specific thing that's wrong, and size the fix to the problem. And then make the next investigation cheaper than this one.

Has a "harmless" upgrade ever bitten you? I'd like to hear the story in the comments.

I also told this story on video, if you'd rather watch:

Originally published on the Tech Swamy blog. This was one thread of a longer engagement, and the full case study covers the rest. If your team is spending more time fighting its system than building on it, that's the work we do at Tech Swamy.

The Surprising Truth about Promises

Vijay Rangan — Wed, 21 Feb 2024 11:27:51 +0000

As developers, we often work with promises and callbacks in our code. While they may seem similar at first glance, there are some important differences to keep in mind. In this article, we will explore these differences and gain a deeper understanding of how promises and callbacks work.

Through an execution order experiment, we will examine the task queue versus the microtask queue and how they impact the behavior of callback functions and promises. By the end of this article, we will have a clear understanding of the promise mechanism and the microtask queue, as well as how they differ from callback functions and the task queue.

Key Takeaways

Promises and callbacks have important differences in how they execute in code.
The microtask queue runs before the task queue, impacting the order of execution.

The Experiment

I setup an experiment to observe the execution order of promises and callbacks. The sample code below sets up a promise that logs a value and a callback function that uses setTimeout to log the same value.

const promise = new Promise(resolve => {
  resolve('promise value');
});

setTimeout(() => {
  console.log('setTimeout value');
}, 0);

promise.then(value => {
  console.log(value);
});

At first glance, it may seem that the order of execution would be the same regardless of the order of the code. However, the order of execution is actually dependent on the type of queue being used.

Depending on the type of async mechanism you use, one of two queues are used internally

Microtask queue —or—
Task queue (aka Macrotask queue)

The main difference between the microtask queue and the task queue is that every task that’s been queued up in the microtask is run first, irrespective of how many items are there in the task queue.

To test this, I switched the order of the code and ran it again:

setTimeout(() => {
  console.log('setTimeout value');
}, 0);

const promise = new Promise(resolve => {
  resolve('promise value');
});

promise.then(value => {
  console.log(value);
});

The result is still the same. From this it is clear that promises use the microtask queue, while callbacks like setTimeout use the task queue. This is why the setTimeout function always runs after the Promise.

Understanding this difference between the task queue and the microtask queue is important when working with promises and callback functions. It can help prevent unexpected behavior and ensure that our code runs as intended.

If you’re the kind of person that likes consuming tech content via videos, you can find a video of this on my YouTube channel.

YouTube link : The Surprising Truth about JavaScript Promises

If you liked this article and you learned something, don’t be shy… show some love with a ❤️ 😀

Until next time…