Chapter 5 — Race Conditions in Single-Threaded JS

One thread, many interleavings: how two async calls corrupt shared state, and how to find, prove and fix it

Part 2 of the async core. Prerequisites: Chapter 4 — async/await Traps (every await is a yield point) and Chapter 1 — The Event Loop Under Pressure. Database background: the isolation and locking chapters of PostgreSQL First Principles. Practice: the gym, exercises 01-search-box, 02-credit-wallet and 05-webhook-handler.

How to Read This Chapter

This is the chapter the interview is built around. You will be handed code that passes its tests, and asked "what happens if two of these run at once?" The answer is never "JavaScript is single-threaded, so nothing". This chapter gives you the mechanism, a taxonomy of the eight races you will meet, a method for spotting them in code you did not write, a way to prove them with a test, and the fixes with their limits.

Read Parts 1 and 2 slowly. Everything else is the same idea applied to different state.

Part 1: What a Race Is, Precisely

A race condition is a bug where the outcome depends on the relative timing of interleaved async steps. Each step is correct on its own. Every interleaving is a legal execution. Some interleavings produce a wrong result.

For a race, you need three things:

1. Shared mutable state. A variable, a Map, a cache entry, a React state value, a database row, a Redis key, a file, a Stripe customer record.
2. At least two flows that touch it. Two requests, two clicks, two webhook deliveries, a timer and a request, two instances of your service.
3. A yield point between a read and a write that depends on that read. In JavaScript that means an await, a callback, or an event. In a database it means the gap between two statements.

Remove any one of the three and the race is gone. Every fix in Part 7 removes one of them: it stops the state being shared, stops the flows overlapping, or removes the gap.

Two things are not races in this sense. A slow operation is not a race. A bug that happens on every run, whatever the timing, is not a race. Races are the bugs that pass every test you wrote, because tests run one call at a time.

Part 2: Why One Thread Still Races

JavaScript has one thread per event loop, and run-to-completion: once a callback starts, no other JavaScript on that thread runs until it returns or reaches an await. So this is safe, even with a thousand concurrent requests:

// Synchronous: nothing else can run between the read and the write.
function chargeSync(wallet, amount) {
  if (wallet.balance < amount) throw new Error('insufficient credits');
  wallet.balance -= amount;
}

Add one await in the middle, and it is not:

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
const balances = new Map([['u1', 100]]);
const db = {
  async getBalance(id) { await sleep(5); return balances.get(id); },
  async setBalance(id, v) { await sleep(5); balances.set(id, v); },
};

async function charge(userId, amount) {
  const balance = await db.getBalance(userId);
  if (balance < amount) throw new Error('insufficient credits');
  await db.setBalance(userId, balance - amount);
  return balance - amount;
}

const results = await Promise.allSettled([charge('u1', 80), charge('u1', 80)]);
// [ 'fulfilled', 'fulfilled' ], balance 20: 160 credits spent from a balance of 100

The critical section, from reading balance to writing balance - amount, spans an await. At that await, charge A pauses and the event loop is free to run charge B, which reads the same 100.

Concurrency is not parallelism. Concurrency means tasks take turns, interleaving at yield points. Parallelism means tasks run at the same instant on different cores. Node gives you concurrency on one thread; parallelism needs worker_threads or more processes (Chapter 8). Races need only concurrency.

That last row is the good news. In JavaScript every place a race can start is marked in the code by await. You can find them by reading.

Now drag the latencies yourself. Try to find the timing where both charges succeed, then turn on the fix.

Part 3: The Taxonomy

Eight shapes cover almost every race you will meet. Learn to name them: "this is a check-then-act across an await" is a better interview answer than "there might be a race here".

3.1 Stale responses (out-of-order resolution)

Search-as-you-type. The user types a, then ab. Two requests go out. Nothing guarantees they come back in the order they were sent. The request for a hits a cold cache and takes 300 ms; ab takes 100 ms.

let shown = '';
async function onInput(q) {
  const results = await search(q);
  shown = results;   // whoever resolves last wins, not whoever was sent last
}
onInput('a');
onInput('ab');
// 400 ms later: shown === 'results for "a"'

The fixes, both verified (the buggy version shows "a", both fixes show "ab"):

// Fix 1: latest wins
let latest = 0;
async function onInput(q) {
  const id = ++latest;
  const results = await search(q);
  if (id !== latest) return;   // a newer request exists; drop this response
  shown = results;
}

// Fix 2: abort the previous request
let controller;
async function onInput(q) {
  controller?.abort();
  controller = new AbortController();
  const { signal } = controller;
  try {
    const results = await search(q, { signal });
    if (signal.aborted) return;   // resolved, but aborted before we resumed (Chapter 6)
    shown = results;
  } catch (err) {
    if (err.name === 'AbortError') return;
    throw err;
  }
}

The abort version also stops the work: the browser closes the connection, and the server can stop too, if it listens (Chapter 6). Add a debounce in front so you send fewer requests (Chapter 7), but a debounce alone does not fix this race. It makes it rarer, which makes it harder to reproduce.

3.2 Check-then-act across an await

The wallet in Part 2 is the classic case. The second most common is "create if not exists":

async function getOrCreateCustomer(email) {
  const existing = await db.customers.findByEmail(email);
  if (existing) return existing;
  return db.customers.insert({ email });   // two concurrent signups both reach here
}
await Promise.all([getOrCreateCustomer('a@x.io'), getOrCreateCustomer('a@x.io')]);
// two rows for one email

The same shape appears as: "grant the referral bonus if not granted yet", "create the Stripe customer if the user has none", "start the job if it is not already running", "send the welcome email if not sent".

The fix is to let the database make the check and the write one atomic step: a unique constraint plus INSERT … ON CONFLICT DO NOTHING. For an external system that has no constraint you can use (creating a Stripe customer), use that system's idempotency key, or claim the right to create it in your own database first.

3.3 Read-modify-write: lost updates

async function recordUsage(userId, tokens) {
  const used = await kv.get(`usage:${userId}`);
  await kv.set(`usage:${userId}`, used + tokens);
}
await Promise.all([recordUsage('u1', 100), recordUsage('u1', 250)]);
// stored 250, expected 350: the 100 is lost

Unlike check-then-act, nothing is rejected and nothing is duplicated. A change just disappears, with no error. That makes lost updates the hardest race to notice. The usual symptom is a total that is slightly too low.

Fixes, in order of preference: an atomic operation in the store (INCRBY, UPDATE … SET used = used + $1, $inc in MongoDB, HINCRBY); optimistic concurrency, where you write only if the version is unchanged (Part 7); or a lock around the read and the write. The same race hits whole documents: two admins edit the same settings JSON, and the second save wipes the first admin's change. Use a version column there.

3.4 Double submit and duplicate jobs

The user double-taps "Generate". The mobile client retries a POST after a timeout, although the first attempt succeeded. A queue redelivers a job because the worker's acknowledgement was lost. Each is the same operation arriving twice, and the server cannot tell from the request body alone.

Disabling the button while the request is pending is good UX, but it is not a fix: it does nothing about client retries, two tabs, or a script. The server-side fix is an idempotency key: the client creates a UUID when the user starts the action, and sends it with every attempt. The server stores it with a unique constraint, in the same transaction as the effect, and stores the response so that a repeat gets the same answer. While the first request is still in progress, a repeat should get 409 or wait, never start a second run.

3.5 Initialisation races

let client;
async function getClient() {
  if (!client) client = await connect();   // check-then-act on `client`
  return client;
}
const [a, b] = await Promise.all([getClient(), getClient()]);
// connect() called twice; a !== b; the first client is overwritten and leaked

Both callers see client undefined, both start connect(), and the slower one overwrites the faster. You get two pools, one of them leaked with its connections still open. The same bug hits lazy-loaded config, a JWKS fetch, a vector index loaded on first use, and OAuth token refresh.

Cache the promise, not the result. The assignment then happens synchronously, before any yield point, so run-to-completion makes it atomic. And clear it on failure, or one ECONNREFUSED at boot is cached forever (verified: the first call fails, the second retries and succeeds):

let clientPromise;
export function getClient() {
  clientPromise ??= connect().catch((err) => {
    clientPromise = undefined;   // let the next caller retry
    throw err;
  });
  return clientPromise;
}

3.6 React effect races

React components hit three race shapes.

Stale responses in useEffect. It is 3.1 again: the id prop changes from 1 to 2, the response for 1 arrives last, and the panel shows customer 1 under customer 2's heading.

useEffect(() => {
  const controller = new AbortController();
  fetch(`/api/customers/${id}`, { signal: controller.signal })
    .then((r) => r.json())
    .then(setCustomer)
    .catch((err) => { if (err.name !== 'AbortError') setError(err); });
  return () => controller.abort();   // runs before the next effect, and on unmount
}, [id]);

Stale closures. A handler captures the state value from the render that created it. After an await, that value can be old:

const [credits, setCredits] = useState(0);
async function onBuy() {
  await api.buyCredits(10);
  setCredits(credits + 10);   // two quick clicks: both closures saw 0, so the screen shows 10
}

setCredits((c) => c + 10) fixes the arithmetic. It is usually better to show the balance the server returns, since the server is the source of truth. If you do, remember that two responses can arrive out of order, so keep the one with the higher ledger version.

State updates after unmount. React 18 removed the warning, and the update is a no-op, but the request still runs, and any side effect in its .then (a toast, analytics, a redirect) still fires after the user has left the page. Cleanup functions handle this. In development, StrictMode mounts, unmounts and re-mounts every effect once, exactly so that missing cleanup shows up as a double fetch (Chapter 6).

3.7 Webhook ordering and duplicates

Payment providers such as Stripe state that webhook events may arrive more than once and out of order. Each delivery is a separate HTTP request, so two deliveries can run concurrently on two instances.

The rules for webhook handlers:

1. Dedupe by event ID: INSERT INTO processed_events (event_id) … with a primary key, in the same transaction as the effect. A duplicate fails the insert and the effect rolls back with it.
2. Never trust arrival order. Guard writes on the event's own timestamp or version. Stripe's created has one-second resolution, so ties are possible. For important state, treat the event as a hint and fetch the current object from the provider's API.
3. Persist before you acknowledge. Return 2xx only after the event is stored; otherwise a crash loses it. Do slow work from a queue (gym exercise 05-webhook-handler).

3.8 Races across processes

You fix the wallet with an in-memory lock per user. Tests pass. In production you run three instances behind a load balancer. Two charges for the same user land on different instances, and each instance has its own Map of locks. Neither lock knows about the other request.

When the state lives in a database, the fix lives in the database:

All seven were run against PostgreSQL 18 with two concurrent sessions: the conditional UPDATE in the second session waited for the first to commit, then updated 0 rows; SKIP LOCKED gave two workers disjoint jobs; the duplicate idempotency key returned no row; the stale version updated 0 rows.

Two cautions. Never hold a row lock or a transaction open across an LLM call. A 30-second generation inside BEGIN … COMMIT holds a connection and the row lock for 30 seconds, and the pool runs dry under load. Charge (or reserve credits) in one short transaction, call the model outside it, then settle in another. And session-level advisory locks (pg_advisory_lock) belong to the connection, so with a pooler in transaction mode they can be released by, or leak to, another client. Prefer the _xact_ variants, which are released at commit.

Part 4: The JS ↔ Postgres Parallel

A race in JavaScript and a race between database transactions are the same bug. If you can explain one, you can explain the other, and interviewers like to hear you make the link.

The rule in both worlds: make the critical section a single atomic step, or hold a lock that every participant must take.

Part 5: How to Spot Races When Reading Code

You cannot see a timing bug by reading one execution path. You have to imagine two at once. Use this procedure on every function that writes state:

1. Find the shared mutable state. Anything that outlives one call: module-level variables, fields on a singleton service, Map caches, React state, rows, Redis keys, files, records at a third party.
2. Find every await between reading that state and writing something that depends on it. Mark them. Each one is a yield point inside a critical section.
3. At each mark, ask: "What if another call of this same function runs here?" Then: what if a different function that writes the same state runs here? Then: what if this runs on another instance?

Worked example. Mark each yield point:

async function redeemCoupon(userId, code) {
  const coupon = await db.coupons.findByCode(code);            // (1) read coupon
  if (!coupon || coupon.uses >= coupon.maxUses) throw new Error('invalid');
  const already = await db.redemptions.find(userId, code);    // (2) yield: can another redeem run here?
  if (already) throw new Error('already used');
  await ledger.credit(userId, coupon.credits);                // (3) yield: the other call passes both checks
  await db.coupons.update(code, { uses: coupon.uses + 1 });   // (4) RMW on `uses`, from the read at (1)
  await db.redemptions.insert({ userId, code });              // (5) the "already used" record comes last
}

Answers: at (2) and (3), a second call from the same user passes both checks, so the user is credited twice (check-then-act). At (4), two different users both write uses + 1 from the same read, so uses goes up by one instead of two, and the coupon can be used beyond maxUses (lost update). The record that would block a repeat, (5), is written last, after the effect. Fix: in one transaction, INSERT INTO redemptions … with a unique (user_id, code) constraint first; then UPDATE coupons SET uses = uses + 1 WHERE code = $1 AND uses < max_uses RETURNING credits; credit only if both succeeded.

Signals that should make you stop and apply the procedure:

Part 6: How to Test for Races

A test that calls charge() once cannot fail on a race. A test that calls it twice with Promise.all usually passes too, because with a fast fake database the interleaving happens to be safe. You need to control the interleaving.

Deterministic tests with controlled deferred promises

Make the fake dependency return a promise that the test resolves by hand. Then the test, not the scheduler, decides the order of steps. Promise.withResolvers() (Node 22) gives you the promise and its resolve together.

import { test } from 'node:test';
import assert from 'node:assert/strict';

function controlledDb(start) {
  const pendingReads = [];
  return {
    balance: start,
    pendingReads,
    getBalance() {
      const d = Promise.withResolvers();
      pendingReads.push(d);
      return d.promise;          // stays pending until the test resolves it
    },
    async setBalance(v) { this.balance = v; },
  };
}

async function charge(db, amount) {
  const balance = await db.getBalance();
  if (balance < amount) throw new Error('insufficient credits');
  await db.setBalance(balance - amount);
}

test('read, read, write, write: both charges pass', async () => {
  const db = controlledDb(100);
  const a = charge(db, 80);
  const b = charge(db, 80);
  assert.equal(db.pendingReads.length, 2);   // both are parked at the same await
  db.pendingReads[0].resolve(db.balance);    // both reads see 100
  db.pendingReads[1].resolve(db.balance);
  const r = await Promise.allSettled([a, b]);
  assert.deepEqual(r.map((x) => x.status), ['fulfilled', 'fulfilled']);
  assert.equal(db.balance, 20);              // the bug, reproduced on every run
});

test('with the lock, the second read is not issued until the first charge is done', async () => {
  const db = controlledDb(100);
  const lockedCharge = (amount) => withLock('wallet', () => charge(db, amount));
  const a = lockedCharge(80);
  const b = lockedCharge(80);
  await new Promise((r) => setImmediate(r));
  assert.equal(db.pendingReads.length, 1);   // b is queued behind a
  db.pendingReads[0].resolve(db.balance);
  await a;
  await new Promise((r) => setImmediate(r));
  db.pendingReads[1].resolve(db.balance);    // b reads 20
  await assert.rejects(b, /insufficient/);
  assert.equal(db.balance, 20);
});

The first test documents the race: it passes on the buggy code, every time. The second states the property the fix must have: the second read is not even issued until the first charge has written. Both pass on Node 22 with the withLock from the build below.

Injecting delays

When the code is too tangled for hand-driven deferreds, add random delays to the fake dependencies and run many times, asserting an invariant rather than an exact sequence:

test('random delays, 200 runs: never overspends', async () => {
  for (let run = 0; run < 200; run++) {
    let stored = 100;
    const jitter = () => new Promise((r) => setTimeout(r, Math.random() * 3));
    const db = {
      async getBalance() { await jitter(); return stored; },
      async setBalance(v) { await jitter(); stored = v; },
    };
    const results = await Promise.allSettled(
      Array.from({ length: 5 }, () => withLock('wallet', () => charge(db, 30))),
    );
    assert.equal(results.filter((r) => r.status === 'fulfilled').length, 3);
    assert.equal(stored, 10);
  }
});

With the lock, this passes. With the lock removed, it fails on the first run (five charges succeed instead of three). Invariants worth asserting: money is conserved, a balance is never negative, a count equals the number of successful calls, each key appears once.

For cross-process races, unit tests are not enough. Write an integration test against a real Postgres that opens two separate connections and runs the two flows on them at the same time. That is what two instances do.

Part 7: Fixes and Their Limits

Every fix removes one of the three ingredients from Part 1. Every fix also has a limit, and naming the limit is what separates a senior answer.

The code for the in-process fixes:

// Single-flight: concurrent callers for the same key share one promise.
const inflight = new Map();
export function singleFlight(key, fn) {
  const existing = inflight.get(key);
  if (existing) return existing;
  const p = Promise.resolve().then(fn).finally(() => {
    if (inflight.get(key) === p) inflight.delete(key);
  });
  inflight.set(key, p);
  return p;
}
// Three concurrent singleFlight('cfg', load) calls: load runs once, all three get 'config'.
// After it settles, the next call runs load again: this dedupes, it does not cache.

// Semaphore: at most `max` concurrent holders.
export function createSemaphore(max) {
  let active = 0;
  const waiters = [];
  return async function run(fn) {
    if (active >= max) await new Promise((resolve) => waiters.push(resolve));
    else active++;
    try { return await fn(); }
    finally {
      const next = waiters.shift();
      if (next) next();   // hand our slot straight to the next waiter
      else active--;
    }
  };
}
// 10 tasks through createSemaphore(3), one of them throwing: peak concurrency 3.

// Optimistic concurrency, with node-postgres.
const { rowCount } = await pool.query(
  'UPDATE agent_configs SET body = $2, version = version + 1 WHERE id = $1 AND version = $3',
  [id, newBody, versionTheEditorLoaded],
);
if (rowCount === 0) throw new ConflictError('Someone else saved this config. Reload and reapply your change.');

And the atomic charge for the credit ledger. The deduction and the ledger row are one statement. A repeated idempotency key violates the unique constraint, which fails the whole statement, so the balance is not touched:

WITH charged AS (
  UPDATE wallets SET balance = balance - $2
  WHERE user_id = $1 AND balance >= $2
  RETURNING user_id, balance
)
INSERT INTO ledger (user_id, amount, idempotency_key)
SELECT user_id, -$2, $3 FROM charged
RETURNING id, (SELECT balance FROM charged) AS balance;

Verified on PostgreSQL 18: the first call returns the new balance 80; the same key again raises duplicate key value violates unique constraint and the balance stays 80; a charge larger than the balance returns no row. In the app, no row means "insufficient credits", and error code 23505 means "already charged": look up and return the original result. Do not use ON CONFLICT DO NOTHING here. A data-modifying CTE runs even when the outer INSERT does nothing, so the wallet would be charged with no ledger row.

Build: A Keyed Async Mutex

Spec. withLock(key, fn) runs fn and returns a promise for its result or its error.

• Calls with the same key run one at a time, in the order they arrived.
• Calls with different keys do not wait for each other.
• If fn throws, synchronously or by rejecting, the caller gets that error, and the lock is released for the next waiter.
• Keys that are no longer in use are removed, so memory does not grow with the number of users.

const tails = new Map();   // key → promise that settles when the last queued holder is done

export function withLock(key, fn) {
  const prev = tails.get(key) ?? Promise.resolve();
  const run = prev.then(() => fn());     // start after the previous holder settles
  const tail = run.then(noop, noop);     // never rejects, so one failure can't poison the queue
  tails.set(key, tail);
  tail.then(() => {
    if (tails.get(key) === tail) tails.delete(key);   // last one out removes the key
  });
  return run;                            // the caller sees fn's own result or error
}

function noop() {}

export const lockedKeyCount = () => tails.size;

import { test } from 'node:test';
import assert from 'node:assert/strict';
import { withLock, lockedKeyCount } from './with-lock.mjs';

const tick = () => new Promise((r) => setImmediate(r));

test('serialises calls on the same key, in arrival order', async () => {
  const log = [];
  const gates = [Promise.withResolvers(), Promise.withResolvers(), Promise.withResolvers()];
  const runs = gates.map((g, i) =>
    withLock('user:1', async () => {
      log.push(`start ${i}`);
      await g.promise;
      log.push(`end ${i}`);
    }),
  );
  await tick();
  assert.deepEqual(log, ['start 0']);        // 1 and 2 are queued, not running
  gates[2].resolve();
  gates[1].resolve();                        // finishing out of order changes nothing
  await tick();
  assert.deepEqual(log, ['start 0']);
  gates[0].resolve();
  await Promise.all(runs);
  assert.deepEqual(log, ['start 0', 'end 0', 'start 1', 'end 1', 'start 2', 'end 2']);
});

test('different keys run at the same time', async () => {
  const gate = Promise.withResolvers();
  let bRan = false;
  const a = withLock('user:1', () => gate.promise);
  const b = withLock('user:2', async () => { bRan = true; });
  await b;                                   // b finishes while a still holds user:1
  assert.equal(bRan, true);
  gate.resolve();
  await a;
});

test('releases the lock when fn throws or rejects', async () => {
  const first = withLock('k', async () => { throw new Error('boom'); });
  const sync = withLock('k', () => { throw new Error('sync boom'); });
  const third = withLock('k', async () => 'ran');
  await assert.rejects(first, /boom/);
  await assert.rejects(sync, /sync boom/);
  assert.equal(await third, 'ran');
});

test('returns the result and removes the key afterwards', async () => {
  assert.equal(await withLock('x', async () => 42), 42);
  await tick();
  assert.equal(lockedKeyCount(), 0);
});

test('re-entering the same key deadlocks (documented limitation)', async () => {
  const outer = withLock('re', () => withLock('re', async () => 'inner'));
  const timeout = new Promise((r) => setTimeout(() => r('deadlock'), 50));
  assert.equal(await Promise.race([outer, timeout]), 'deadlock');
});

Investigation: Charged Twice for One Story

Spot the Bug

Drill 1: four recovery paths, one refund

A failed generation must be refunded once. Four code paths can call this: the watchdog, the retry-exhausted handler, the admin "refund" button, and startup recovery.

export async function refundIfNeeded(jobId) {
  const job = await db.jobs.findById(jobId);
  if (job.status !== 'failed' || job.refundedAt) return;

  await ledger.credit(job.userId, job.cost, { reason: 'refund', ref: job.id });
  await db.jobs.update(jobId, { refundedAt: new Date() });
  logger.info({ jobId }, 'refunded');
}

What's wrong?

await withTransaction(pool, async (tx) => {
  const { rows } = await tx.query(
    `UPDATE jobs SET refunded_at = now()
     WHERE id = $1 AND status = 'failed' AND refunded_at IS NULL
     RETURNING user_id, cost`,
    [jobId],
  );
  if (rows.length === 0) return;   // already refunded, or not failed
  await tx.query(
    'INSERT INTO ledger (user_id, amount, ref) VALUES ($1, $2, $3)',
    [rows[0].user_id, rows[0].cost, `refund:${jobId}`],
  );
});

Drill 2: the customer panel

function CustomerPanel({ customerId }) {
  const [customer, setCustomer] = useState(null);

  useEffect(() => {
    setCustomer(null);
    fetch(`/api/admin/customers/${customerId}`)
      .then((r) => r.json())
      .then((data) => setCustomer(data));
  }, [customerId]);

  if (!customer) return <Spinner />;
  return <CustomerDetails customer={customer} onRefund={() => refund(customer.id)} />;
}

What's wrong?

useEffect(() => {
  const controller = new AbortController();
  setCustomer(null);
  fetch(`/api/admin/customers/${customerId}`, { signal: controller.signal })
    .then((r) => r.json())
    .then((data) => { if (!controller.signal.aborted) setCustomer(data); })
    .catch((err) => { if (err.name !== 'AbortError') setError(err); });
  return () => controller.abort();
}, [customerId]);

Drill 3: token refresh

let accessToken = loadToken();

export async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken();   // POST /oauth/token with the stored refresh token
    res = await fetch(url, withAuth(opts, accessToken));
  }
  return res;
}

The dashboard loads six widgets in parallel. Users report being logged out at random, about once a day.

What's wrong?

let refreshing = null;
function refreshOnce() {
  refreshing ??= refreshAccessToken().finally(() => { refreshing = null; });
  return refreshing;
}
// in apiFetch:
if (res.status === 401) {
  accessToken = await refreshOnce();
  res = await fetch(url, withAuth(opts, accessToken));
}

Drill 4: a daily quota in Redis

export async function consumeQuota(userId) {
  const key = `quota:${userId}:${todayUtc()}`;
  const used = Number(await redis.get(key)) || 0;
  if (used >= DAILY_LIMIT) throw new QuotaExceededError();
  await redis.set(key, used + 1, 'EX', 86_400);
}

What's wrong?

export async function consumeQuota(userId) {
  const key = `quota:${userId}:${todayUtc()}`;
  const [[, used]] = await redis.multi().incr(key).expire(key, 86_400, 'NX').exec();
  if (used > DAILY_LIMIT) throw new QuotaExceededError();
}

The Causal Chains

Review Checklist

1. List the shared mutable state: module-level let, singleton fields, Map caches, React state, rows, Redis keys. For each, find every writer.
2. For each writer, mark every await between the read and the dependent write. Ask "what if another call runs here?" and "what if it runs on another instance?".
3. if (!x) x = await …: cache the promise instead.
4. get followed by set on the same key: use an atomic operation or a version check.
5. A balance, quota or stock read into JS and written back: use one conditional UPDATE … WHERE … RETURNING.
6. "Create if not exists" with no unique constraint behind it.
7. Charging, sending or creating POST endpoints, and job handlers, with no idempotency key; "done" flags written after the effect.
8. setState(await …) in effects and handlers with no cleanup, abort or latest-wins check.
9. Webhook handlers: dedupe by event ID? Guarded by event time? Persist before 2xx?
10. Any in-memory lock, dedupe set or rate limiter in a service that runs on more than one instance.

What's Next

Several fixes in this chapter depend on stopping work that is no longer wanted: the old search request, the losing provider call, the effect for an unmounted component. Chapter 6 — Cancellation and Cleanup covers AbortController in depth, along with the abort race that the signal.aborted checks above guard against.