DEV Community: Karuha

NFC vs QR: which business card actually gets scanned

Karuha — Wed, 09 Sep 2026 04:33:34 +0000

NFC cards break on range, metal, and iOS confirmation. QR codes break on print density and light. Neither format is the contact data — both just deliver a URL.

A tap-to-share card works against your own phone because you know where the antenna sits. Hand the same card to someone at a conference and the tap does nothing: no vibration, no popup, nothing to tell either of you whether it even tried. The QR printed on the back of that card is usually what saves the exchange.

Both formats move the same handful of bytes: a name, a title, a URL. The difference is entirely in how those bytes get from the card to the phone.

What's actually being transmitted

An NFC business card is a small chip, usually in plastic or metal, storing an NDEF record — typically a URI, occasionally a full vCard. Tapping it against a phone's NFC antenna powers the chip (no battery) and the OS reads the record.

A QR-code card encodes the same URI as a matrix of squares. A camera reads it instead of a radio.

Neither one is "the data." Both are delivery mechanisms for a link. The two common failure modes have nothing to do with vCard fields. They're specific to radios and cameras.

Where NFC actually breaks

The phone has to be looking for a tag. Android only scans when NFC is on and the screen is unlocked. iPhone background tag reading exists since the XS; older models need an app that explicitly opens the scanner.

The tag format has to match what the OS expects. iOS's background reader only picks up specific NDEF record types, then asks the user to confirm before any app sees the data. "Tap and done" is never literally true on iPhone.

Range is short and inconsistent. Reliable reads happen within about 4cm, and that number moves by device. A card that works against your Pixel can fail against someone else's phone for no reason related to the card.

Metal defeats it outright. A metal NFC card needs an antenna cutout or it blocks its own signal. Plastic cards read more consistently. This is a design tradeoff, not a manufacturing defect.

Where QR actually breaks

The failure modes are almost the inverse: physical, not electronic.

Density scales with content. A URL encodes into a sparse, forgiving pattern. A QR holding an entire vCard (name, phone, title, address) is several times denser and needs better light, a steadier hand, and a cleaner print. Point the code at a page URL and put the .vcf behind a button on that page, not inside the code itself.

Light and print quality matter more than the code. A code that scans off a bright phone screen can fail on a badge under fluorescent conference lighting, especially if it was printed small or on a low-contrast background.

It needs a camera that recognizes QR, which every iPhone since iOS 11 and effectively every Android phone since Android 9 does natively. This is the one area where QR has had fewer compatibility surprises than NFC for years.

Cost, and who controls the card afterward

An NFC card is a physical object with a per-unit cost: plastic roughly $15–$25, metal $40 and up, before any software subscription. Some vendors in this space don't publish that subscription pricing at all.

A QR code costs nothing to generate and nothing to reprint. That's also its main hardware limitation: there's no tactile "tap" moment, and a printed code can be photographed and reused. An NFC chip can't be cloned by a photo.

A two-minute test if you already have both

Tap the NFC card against your own phone with the screen unlocked (Android only scans in that state). If nothing happens, check whether NFC is toggled on before blaming the card.
Hand the same card to someone with a different phone brand and watch what happens with no prompting from you.
Print the QR at the size you'll actually use, then scan it from arm's length under normal indoor light, not from six inches under your desk lamp.
Compare which one a stranger gets through faster, unprompted. That result matters more than either spec sheet.

What neither format fixes

Whichever one gets the tap or the scan through, it hands over a link. The first impression is the page behind it, not the transmission method.

NFC is the better fit for repeat, one-on-one taps where you know both phones support it. QR remains the more compatible option for anything printed at scale or handed to someone whose phone you can't predict.

I work on Nameplate, a page builder with tracked QR links and a vCard export. This is adapted from our longer guide. We don't sell NFC hardware.

HackerRank AI-Assisted Interview: If the Assistant Won't Write Code, Check the Question Type

Karuha — Tue, 08 Sep 2026 07:38:17 +0000

A HackerRank AI-assisted interview is a live round where the hiring company turns on an in-IDE assistant. If that assistant refuses to write a full solution, you are probably on a single-file Coding question in Guarded mode, not a broken panel. Code Repos run Unguarded, with Plan mode and Agent mode, and the interviewer sees every prompt in real time.

Google autocomplete still surfaces hackerrank ai assisted interview practice and hackerrank ai assisted interview reddit. Most of those threads collapse the format into "they gave me Copilot." The candidate knowledge base, last updated 11 days ago, is more specific than that. The format splits by question type, and the two sides do not behave the same.

What actually gets turned on?

You cannot enable the assistant yourself. HackerRank's candidate docs are blunt: it appears only when the hiring company enables it for that interview, and only on supported question types. If the panel is missing, treat the round as a standard live coding session. Using an outside model in that case is the same as any other unauthorized aid.

Two interviewer UIs exist right now. The new candidate article describes the current Interview experience. The admin article still labels itself as the legacy experience. You can tell which one you got from the workspace: a single editor vs an Agentic Development Environment with a repo, terminal, and file tree.

Default model, when the company does not pin one, is GPT-5.6 Terra. The selector can also offer Claude Opus 5 / Sonnet 5 / Haiku 4.5 and GPT-5.6 Sol / Luna. The set on screen is whatever that company configured. Do not spend the first three minutes hunting for a model that is not there.

Why does Guarded mode look broken?

This is the part Reddit threads keep misreading.

In the new Interview experience, HackerRank maps the assistant like this:

Question type	Workspace	Mode	What the assistant will do
Coding	Single-file editor	Guarded	Syntax, navigation, errors, concepts. No complete solutions.
Code Repos	Agentic Development Environment	Unguarded	Plan mode + Agent mode: investigate, generate, edit files, fix issues.

That table is from the candidate knowledge base, not a blog recap. If you paste "write the function" into a single-file Coding question and the assistant talks about the algorithm instead of dumping a passing solution, that is the product working as designed.

The legacy admin FAQ still says "in interviews the assistant operates in unguarded mode." That sentence is about the interview product as opposed to HackerRank Tests (the take-home / OA product), where the assistant stays guarded and will not reveal full solutions. It is not a promise that every live question will generate code. On legacy Coding questions, even unguarded mode only exposes Ask mode. Plan, Agent, inline completions, and model switching are documented as unavailable in Guarded mode, and they only show up on Project / Code Repository questions when Unguarded is on.

So the first diagnostic, before you panic that "AI is off":

Is the panel visible at all? If not, the company did not enable it, or this question type does not support it.
Are you in a single file or a repo? Single file → expect Ask, not an agent that rewrites the file.
Did a Pending tool call dialog appear? That is Agent mode. You have to Allow or Cancel. Ignoring it is not a stall; it is a decision the interviewer can see.

HackerRank's Summer 2026 release added 159 Plan-Build-Review repository tasks for interviews. The industry default is drifting toward the repo side. Do not walk in having only practiced LeetCode in a blank editor.

What does the interviewer actually see?

Three surfaces, all from HackerRank's own interviewer docs — not from "someone on Blind said":

Live panel. Prompts and assistant replies stream to the interviewer as they happen. Plan, Ask, and Agent are all visible. Inline completions you accept land in the shared editor.
Chat transcript in the interview report. The interview report has an AI Assistant Chat control on both Coding and Code Repos responses. Nothing you typed into the panel is off the record.
Diff View, but only on front-end, back-end, and full-stack questions. It compares the project at the start of the interview with the current tree. It is not a hidden plagiarism score. It is a "what changed" view.

HackerRank's admin FAQ also says Plan mode is optional. You can go Ask → Agent, or live in Agent the whole time. Skipping Plan is allowed. It is also obvious, because the transcript then has no plan. Interviewers are told they can weigh those Plan interactions as part of how you collaborate with AI. That is not a published numeric rubric. It is a visible absence.

Ask mode has a mechanical rule that eats people: you have to tag the problem statement. Untagged questions get generic answers. The interviewer sees you retry the same vague prompt three times. Tag it once.

You can also choose not to use the assistant at all. That is documented. It is a valid strategy on a Guarded Coding question where the panel cannot write the solution anyway. On a Code Repo ticket, sitting next to an unused agent for 40 minutes is a different signal — you are leaving a tool on the table that the format was built to watch you use.

What does a strong Code Repo session look like?

Take a ticket that shows up in real repo rounds: implement LRU cache, capacity 2, then hit the hidden eviction order.

This is the first patch models ship. get() returns the value and does not move the key to recent. The public tests still pass if they only check return values.

class LRUCache:
    def __init__(self, capacity: int):
        self.cap = capacity
        self.order = []  # oldest at index 0
        self.data = {}

    def get(self, key: int) -> int:
        if key not in self.data:
            return -1
        # missing: move key to most-recent
        return self.data[key]

    def put(self, key: int, value: int) -> None:
        if key in self.data:
            self.data[key] = value
            self.order.remove(key)
            self.order.append(key)
            return
        if len(self.data) == self.cap:
            old = self.order.pop(0)
            del self.data[old]
        self.data[key] = value
        self.order.append(key)


cache = LRUCache(2)
cache.put(1, 1)
cache.put(2, 2)
assert cache.get(1) == 1
cache.put(3, 3)
print("get(1) after put(3) =", cache.get(1))  # -1  (1 was evicted)
print("get(2) =", cache.get(2))                 # 2

The hidden test is: after get(1), key 1 is more recent than 2, so put(3) should evict 2, not 1. The agent wrote a map plus a list and forgot that get is a recency event. The code compiles. That is the trap.

A session that matches what the interviewer docs say they are watching looks like this:

Plan mode first, no code. One paragraph: hash map plus recency list, get and put both bump recency, evict the head on overflow. Edge case: get on a missing key must not shuffle the list. Plan mode, per HackerRank, does not edit files. If the plan already skipped get recency, Agent will implement the skip.
Allow the tool call, then read the diff before Accept. The Pending dialog is a gate. Cancel is a documented, legal action. Accepting a 40-line rewrite you have not read is the thing Diff View exists to show.
Say the bug out loud, then patch one line. get needs self.order.remove(key); self.order.append(key) before the return. That edit is worth more than a clean Agent dump, because the transcript now has: plan → generation → you catching the model.

Fixed get:

    def get(self, key: int) -> int:
        if key not in self.data:
            return -1
        self.order.remove(key)
        self.order.append(key)
        return self.data[key]

Rerun the same four calls. get(1) after put(3) is now 1, and get(2) is -1. That is the whole interview skill in twelve lines: the assistant wrote something that looked done, and you refused to ship it.

On a Guarded single-file question the same LRU still appears, but the assistant will not dump this class for you. Ask about "what recency means on get" or "why a dict alone is not enough." Then you type. The transcript still exists. The prompts are the answer.

How is this different from a HackerRank OA?

Do not mix the two products.

Interview (this article): a human is on the call. AI use is in the open. The report is a chat transcript, not a plagiarism flag for using the panel.

Tests / Screen (the OA / take-home): the admin FAQ says the assistant stays in Guarded mode and will not reveal full solutions. Proctoring, tab switches, and integrity reports are a different stack. "Can I use ChatGPT during the OA?" is not this format. If your recruiter said "HackerRank assessment" with no interviewer on the calendar, you are probably in Tests.

If the pipeline is OA then live, those are two preps. The OA side is take-home / timed coding. The live side is the format above. aceround.app — an AI interview assistant — is built for the live round, including catching a bad AI patch while someone is watching. The same desktop client also covers coding-test / OA practice; do not walk into Screen with Interview habits, or the other way around.

Ask the recruiter the only question that changes the plan: is this an AI-assisted Interview, or a HackerRank test? If they do not know, assume standard until the panel appears.

A 20-minute practice you can run tonight

You do not need HackerRank's IDE to rehearse the judgment the format scores.

Pick a small repo bug, not a blank-editor LeetCode. LRU, a rate limiter that uses wall-clock time, a pagination off-by-one.
Write a five-line plan in a comment. No code.
Ask any coding model for the implementation. Do not paste it in yet.
Run one hidden case you did not put in the prompt. For LRU: put 1, put 2, get 1, put 3.
Narrate the first thing the model got wrong, then patch it yourself.

If you cannot find the bug in step 4, you are not ready for Unguarded Agent mode. That is the actual practice, not memorizing Plan Mode's UI labels.

The question worth leaving in the comments: when the assistant is on, do you still write the first draft yourself, or do you start in Agent and only keep the edits you can defend?

Sources: HackerRank candidate KB — AI Assistant in Interview (updated 11 days ago); HackerRank admin KB — AI-Assisted Interviews (legacy UI, updated 8 days ago); Interview Report; Summer 2026 release notes (159 Plan-Build-Review repo tasks).

Disclosure: I used AI to help draft and edit this post. The Guarded vs Unguarded split, feature tables, and interviewer surfaces are from HackerRank's public knowledge base, checked today. The LRU example is a local Python replay, not a dump from an interview session.

The Second Worker Never Saw Job 2

Karuha — Fri, 04 Sep 2026 10:11:14 +0000

SELECT … FOR UPDATE LIMIT 1 does not mean "give me the next free job." It means "lock the first matching row, and wait if somebody else already has it." Worker 2 parks on job 1. Job 2 sits queued. SKIP LOCKED, added in PostgreSQL 9.5, is the clause that hands worker 2 the next unlocked row instead.

I replayed it on a five-row table with two workers. Same shape: CPU bored, queue depth 4, throughput 1.

What does `FOR UPDATE LIMIT 1` actually wait on?

The locking clause lives in the PostgreSQL 18 SELECT docs. Default behavior: if the row you want is already locked, you wait. NOWAIT errors. SKIP LOCKED skips.

None of FOR NO KEY UPDATE, FOR SHARE, FOR KEY SHARE, NOWAIT, or SKIP LOCKED are in the SQL standard. Postgres documented that in the same page. So "I'll write standard SQL and the queue will fan out" is not an answer.

The usual claim query looks innocent:

BEGIN;
SELECT id
FROM jobs
WHERE status = 'queued'
ORDER BY id
FOR UPDATE
LIMIT 1;

UPDATE jobs SET status = 'running' WHERE id = /* that id */;
-- work happens here, still inside the transaction
COMMIT;

Worker 1 takes job 1 and holds the row lock until COMMIT. Worker 2's identical SELECT wants job 1 first — ORDER BY id LIMIT 1 — and blocks.

Job 2 is still queued. Nobody is running it.

Why is job 2 still queued while worker 2 is idle?

Because LIMIT 1 applies to returned rows, not to "rows I am willing to wait on." Worker 2 is still trying to return job 1. It has not moved on.

Postgres is explicit about another version of this trap: "If a LIMIT is used, locking stops once enough rows have been returned to satisfy the limit (but note that rows skipped over by OFFSET will get locked)."

So:

Clause	Locked row in front of you	Job 2
`FOR UPDATE` (default)	wait	sits there
`FOR UPDATE NOWAIT`	error, transaction can abort	never attempted
`FOR UPDATE SKIP LOCKED`	skip	claimed

SKIP LOCKED shipped in PostgreSQL 9.5 ("Add SELECT option SKIP LOCKED to skip locked rows", Thomas Munro). The 18 docs still warn that skipping locked rows "provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table."

That last clause is the interview sentence. Queues: yes. Account balances: no.

Can you prove the wait without standing up Postgres?

Yes. A 70-line in-memory table is enough to encode the three lock policies and the OFFSET footgun. I ran this locally before writing the rest of the post; it printed skip-locked assertions passed.

class MiniQueue {
  constructor(ids) {
    this.rows = ids.map((id) => ({
      id, status: 'queued', lock: null, claimedBy: null,
    }));
  }

  claim(worker, { skipLocked = false, nowait = false } = {}) {
    for (const row of this.rows) {
      if (row.status !== 'queued') continue;
      if (row.lock) {
        if (skipLocked) continue;
        if (nowait) {
          const err = new Error('could not obtain lock on row in relation "jobs"');
          err.code = 'NOWAIT';
          throw err;
        }
        return { blocked: true, waitingOn: row.id, job: null };
      }
      row.lock = worker;
      row.claimedBy = worker;
      return { blocked: false, waitingOn: null, job: row.id };
    }
    return { blocked: false, waitingOn: null, job: null };
  }

  commit(worker) {
    for (const row of this.rows) {
      if (row.lock === worker) {
        row.lock = null;
        if (row.claimedBy === worker) row.status = 'running';
      }
    }
  }
}

The wait case is the one people draw wrong on a whiteboard:

const q = new MiniQueue([1, 2, 3, 4, 5]);
const a = q.claim('A');            // job 1
const b = q.claim('B');            // blocked on 1, job === null
assert(b.waitingOn === 1);
assert(q.rows.find((r) => r.id === 2).status === 'queued');

Worker B does not "fall through" to job 2. Job 2's status never changes. That is the whole bug.

Flip the flag:

const q = new MiniQueue([1, 2, 3, 4, 5]);
const a = q.claim('A', { skipLocked: true }); // 1
const b = q.claim('B', { skipLocked: true }); // 2
const c = q.claim('C', { skipLocked: true }); // 3
assert(new Set([a.job, b.job, c.job]).size === 3);

Three workers, three distinct jobs, zero waits. NOWAIT on the same setup throws could not obtain lock on row in relation "jobs" instead of skipping — which matches the 9.5 release note: it does not throw for locked rows the way NOWAIT does.

After A commits, job 1 is running and unlocked. B with SKIP LOCKED then takes job 2, not a second copy of job 1. The lock and the status are different columns in your head even when they live on the same row.

Why does `OFFSET` lock rows you never returned?

Because Postgres said so, in the sentence I quoted above. I encoded it:

selectForUpdate(worker, { offset = 0, limit = 1, skipLocked = false } = {}) {
  let skipped = 0, taken = 0;
  const locked = [], returned = [];
  for (const row of this.rows) {
    if (row.status !== 'queued') continue;
    if (row.lock) {
      if (skipLocked) continue;
      return { blocked: true, locked, returned };
    }
    row.lock = worker;
    locked.push(row.id);
    if (skipped < offset) { skipped += 1; continue; }
    if (taken < limit) {
      row.claimedBy = worker;
      returned.push(row.id);
      taken += 1;
      if (taken >= limit) break;
    }
  }
  return { blocked: false, locked, returned };
}

OFFSET 1 LIMIT 1 on jobs [1, 2, 3] returns job 2 and also locks job 1. Worker B with SKIP LOCKED is forced onto job 3.

Do not paginate a queue with OFFSET. Use WHERE id > $last or SKIP LOCKED plus a real cursor. OFFSET in a locker is how you accidentally serialize workers on a row you did not even claim.

How do you say this in the interview?

I walk it as four beats, then stop.

Name the default. FOR UPDATE LIMIT 1 waits on the first matching row. Extra workers go idle while later rows sit queued.
Name the clause. SKIP LOCKED skips rows that cannot be locked immediately. Official docs restrict that to queue-like tables because the snapshot is inconsistent on purpose.
Name the sibling. NOWAIT fails the statement. Retries of NOWAIT still stampede the same hot row. That is not a queue.
Name the footgun. OFFSET locks skipped rows. I have the sentence from the SELECT page; I do not paraphrase it.

Then the production shape: claim and UPDATE in a short transaction, COMMIT, then do the work. Holding FOR UPDATE across an HTTP call is how worker 2 waits five minutes for job 1's Stripe round-trip while job 2–5 idle.

This is not a toy pattern. Graphile Worker claims with limit ${batchSize} for update skip locked. If an interviewer asks "have you seen this outside a blog," that file is the receipt.

If you are rehearsing the same job-queue answer for a Staff-loop system-design round — multiple consumers, no double-processing, what you do when a worker dies mid-job — walk the wait / NOWAIT / SKIP LOCKED table out loud, then add the lock-hold timeout. aceround.app is the AI interview assistant I use to get pushed on the follow-up ("the worker crashed, job 1 stays running, now what?"). The SQL does not change because the interviewer added a crash; the status machine around it does.

What I still want to hear in a loop: how you recover a lock that outlived the process. SKIP LOCKED does not help you there. A locked_at timestamp plus a reclaim query does. That is a different pad.

This post was drafted with AI assistance and then edited against the PostgreSQL 18 SELECT locking clause, the PostgreSQL 9.5 release notes, and Graphile Worker's getJobs.ts. The Node assertions were run locally before publish.

Forgot client.release()? Postgres Never Sees Request 11

Karuha — Thu, 03 Sep 2026 08:27:27 +0000

If pg_stat_activity is quiet and /health is still 200, it is not slow SQL. node-postgres defaults max to 10 and connectionTimeoutMillis to 0. Skip client.release() after pool.connect(), and request 11 never reaches Postgres — it waits in a FIFO queue with no timer.

What does the interviewer actually mean by "the pool is exhausted"?

They do not mean "Postgres hit max_connections."

PostgreSQL's default max_connections is typically 100, with 3 slots reserved for superusers. That is a server cap. The Node pool is a process cap. node-postgres will create clients lazily up to max, then park extra connect() calls in a FIFO wait list until somebody calls release().

Two different ceilings, two different dashboards:

Layer	Default	What "full" looks like
`pg.Pool` in one Node process	`max: 10`	`waitingCount` climbs, handlers hang or hit `connectionTimeoutMillis`
PostgreSQL	`max_connections` ≈ 100	new backends fail; superuser still has 3 reserved slots

I have walked this on-call more than once. CPU on the database is bored. p99 on the API is 30 seconds. The missing chart is pool.waitingCount.

Why does `pool.connect()` hang instead of throwing?

Because the default timeout is not "a few seconds." It is off.

From the pool docs, connectionTimeoutMillis defaults to 0, which means no timeout. idleTimeoutMillis defaults to 10_000 (idle clients get recycled after 10 seconds). Those two numbers get swapped in people's heads. Idle recycle is not a checkout deadline.

Official warning, almost word for word: if you forget to release, further pool.connect() calls timeout or hang indefinitely when connectionTimeoutMillis is 0.

So the production shape is:

Handler calls const client = await pool.connect().
It awaits something else (a payment API, S3, another SQL client) while still holding the checkout.
Under load, all 10 slots are busy doing not-SQL.
Request 11 waits forever. The process looks "up." Postgres never saw the query.

How do you prove the checkout contract without standing up Postgres?

I do not spin Docker for this drill. The failure is the lease, not the SQL. A tiny pool with max, FIFO waiters, and connectionTimeoutMillis is enough. Save it as pool-release.mjs and run node pool-release.mjs.

import assert from "node:assert/strict";

class MiniPool {
  constructor({ max = 10, connectionTimeoutMillis = 0 } = {}) {
    this.max = max;
    this.connectionTimeoutMillis = connectionTimeoutMillis;
    this.totalCount = 0;
    this.idle = [];
    this.waiters = [];
    this.nextId = 1;
  }
  get idleCount() { return this.idle.length; }
  get waitingCount() { return this.waiters.length; }

  connect() {
    return new Promise((resolve, reject) => {
      const give = (client) => { client.busy = true; resolve(client); };
      if (this.idle.length > 0) return give(this.idle.pop());
      if (this.totalCount < this.max) {
        this.totalCount += 1;
        return give({ id: this.nextId++, busy: true, released: false });
      }
      const waiter = { resolve, reject, timer: null };
      if (this.connectionTimeoutMillis > 0) {
        waiter.timer = setTimeout(() => {
          const i = this.waiters.indexOf(waiter);
          if (i !== -1) this.waiters.splice(i, 1);
          reject(new Error(`connection timeout after ${this.connectionTimeoutMillis}ms`));
        }, this.connectionTimeoutMillis);
      }
      this.waiters.push(waiter);
    });
  }

  release(client) {
    if (!client || client.released) {
      throw new Error("cannot release a client that is not checked out");
    }
    client.busy = false;
    client.released = true;
    if (this.waiters.length > 0) {
      const waiter = this.waiters.shift();
      if (waiter.timer) clearTimeout(waiter.timer);
      waiter.resolve({ id: client.id, busy: true, released: false });
      return;
    }
    this.idle.push({ id: client.id, busy: false, released: false });
  }
}

const wait = (ms) => new Promise((r) => setTimeout(r, ms));

Eight contracts I actually run. The first two are the ones that catch people:

{
  const pool = new MiniPool({ max: 2, connectionTimeoutMillis: 40 });
  await pool.connect();
  await pool.connect();
  await assert.rejects(() => pool.connect(), /connection timeout after 40ms/);
}

{
  const pool = new MiniPool({ max: 2, connectionTimeoutMillis: 0 });
  await pool.connect();
  await pool.connect();
  let settled = false;
  pool.connect().then(() => { settled = "resolved"; }, () => { settled = "rejected"; });
  await wait(50);
  assert.equal(settled, false);
  assert.equal(pool.waitingCount, 1);
}

Then FIFO (first waiter gets the first release()), try/finally still returns the client when the query throws, a handler that holds the client across an 80ms await starves a 30ms checkout, the same handler with finally { pool.release(client) } lets the next request through, and a pool.query helper that connect/release internally can run two sequential queries on max: 1.

That last one is the docs' shortcut: pool.query borrows an idle client and puts it back. Use it for a single statement. Do not use it for a transaction. Postgres transactions are scoped to one backend. Dispatching BEGIN on client A and COMMIT on client B is how you get a "it worked on my laptop" incident.

What do you say when they ask how big `max` should be?

Leave it at 10 until you have a reason. That is not me being cute; it is the pool-sizing guide. The author (Brian Carlson, who maintains pg) writes that he usually does not bother changing the default, and that if the app is starved for connections the queries are the problem.

The napkin math they want out loud:

Postgres usable slots ≈ max_connections - superuser_reserved_connections → 100 − 3 = 97.
12 Node instances × max: 10 = 120 possible backends.
120 > 97. You will get too many connections during a deploy overlap, not during a clever SQL spike.
Safe ceiling per instance: Math.floor(97 / 12) = 8. I still would not jump there on day one. I would keep 10 and put a pooler (PgBouncer / RDS Proxy) in front before I grow instance count.

If you are on Vercel fluid compute or a long-lived container, the same default 10 is the starting point. If you are on a fully stateless worker that dies every request, you still should not set max: 1 unless you enjoy turning batched queries into a single-file line; call pool.end() when the invocation is done.

How do you narrate this in a backend / SRE interview?

I walk the incident, not the class diagram.

Symptom: API p99 blew up. Postgres CPU stayed under 10%. pg_stat_activity had a handful of idle sessions, not a lock pileup.
Mitigate first: shed load, roll back the handler that started awaiting Stripe with a checked-out client, bounce the Node pods so leaked checkouts die with the process. Do not "add max: 50" while you are on fire. That just converts a queue in Node into FATAL: remaining connection slots are reserved for superuser.
Prove the bug: a pad like the one above, plus one production metric: pool.waitingCount. If that number is above 0 while the database is idle, you are leaking checkouts or holding them across I/O.
The fix: try/finally { client.release() } for any transaction. pool.query for one-shot statements. connectionTimeoutMillis: 2000 (the number in the official example) so a leak becomes a fast 500 instead of a silent hang. 2000ms is a product choice, not a law; the law is "0 means never."
Trade-off they will poke: a short checkout timeout fails the user; a missing timeout fails every later user. I would rather fail the leaked request.

If the round is a DevOps / SRE loop, they will ask what you freeze when this burns error budget. Same answer as any saturation bug: stop shipping handlers that hold scarce leases across unbounded I/O, then add the queue metric. I keep a punch-list of those operational follow-ups on aceround.app's DevOps interview guide when I want to rehearse the incident narrative out loud.

What I would not say

I would not say "we should raise max." I would not say "Postgres is slow." I would not claim a connection pooler makes release() optional. A pooler multiplexes TCP. It does not return a client you still hold in JavaScript.

Run the pad. If contract 2 does not stay pending at 50ms, your mental model of connectionTimeoutMillis: 0 is still the idle timeout. Those are not the same knob.

Sources: node-postgres Pool API (max default 10, connectionTimeoutMillis default 0, idleTimeoutMillis default 10000, FIFO wait, must-release warning), pool sizing, PostgreSQL max_connections / superuser_reserved_connections.

This article was drafted with AI assistance and then edited against the official docs and a locally run Node pad (8 assertions). Any leftover mistake is mine.

Drain In-Flight HTTP Before Kubernetes Sends SIGKILL

Karuha — Wed, 02 Sep 2026 04:49:55 +0000

Kubernetes’s default terminationGracePeriodSeconds is 30. That is not a suggestion and it is not process.exit(0). SIGTERM means: stop taking new work, finish what you already accepted, then leave. Miss the window and kubelet sends SIGKILL. The in-flight request you already 200-OK’d on the client side never gets a body.

Google autocomplete for graceful shutdown currently offers golang, spring boot, kubernetes, and nodejs. terminationGracePeriodSeconds fills in with default, default value, 30, k8s, openshift, karpenter. kubernetes sigterm fills in with grace period, vs sigkill, timeout, pid 1. People search the signal. The interview is whether you spend the 30 seconds or throw them away.

What is the interviewer actually asking?

Most answers stop at “I listen for SIGTERM.” Node’s own process docs make that the trap. 'SIGTERM' and 'SIGINT' have default handlers that exit with 128 + signal number. The moment you install a listener, that default goes away. Node will no longer exit. If your handler calls process.exit(0) on the first tick, you did the same thing as having no handler: you tore down sockets that still had a request on them.

The Kubernetes pod-lifecycle page is more specific than a blog post. On delete, the Pod is marked Terminating. The kubelet runs any preStop hook. Then the container runtime sends TERM to process 1. When the grace period expires, remaining processes get SIGKILL. The default grace period in the Pod API is 30 seconds. preStop is not extra time. It comes out of the same 30.

sequenceDiagram
  participant K as kubelet
  participant P as PID 1
  participant S as in-flight request
  K->>P: SIGTERM (grace = 30s)
  P->>P: server.close()
  P->>S: still writing the body
  Note over K,P: preStop + drain share the 30s
  alt in-flight hits 0
    P->>K: exit 0
  else still busy at 30s
    K->>P: SIGKILL
  end

The other half of the contract sits in EndpointSlice. Terminating endpoints report ready: false, so new regular traffic should stop arriving. That does not cancel the POST that already made it onto this process. You still have to drain it.

Why doesn't `server.close()` by itself finish the job?

It stops accepting new connections. Since Node 19.0.0 it also reaps idle keep-alive sockets before the callback fires. The Node docs are explicit: server.close() “closes all connections connected to this server which are not sending a request or waiting for a response.” Active requests stay. That is the correct default. You want those to finish.

Two follow-ups the interviewer will poke.

First: you are on Node 18 in production. Then close() does not reap idle keep-alive. server.close() never fires because a phone from 40 seconds ago is still sitting in keep-alive. The documented escape is closeIdleConnections(), called after close(), because a connection accepted between the two calls would otherwise race. Node 19 made that automatic. Libraries that still support 18 call it anyway. Harmless on 24.

Second: a request that will not finish inside the grace period. A 2-minute report download. A webhook you forwarded to a partner who is slow. close() waits forever. Kubernetes does not. At second 30 you get SIGKILL and the client sees a TCP reset. The Node API for that case is closeAllConnections(), again after close(). It is forceful. The docs say so. Use it as the deadline, not as step one.

How small is the pad version?

A gate, not an http.Server. Clock and grace are injected so the tests do not sleep. wrap is the request. begin is SIGTERM. wait is “I am allowed to exit.” tickForce is second 30.

const REFUSED = "refused";
const FORCED = "forced";
const DRAINED = "drained";

function createShutdownGate({ now, graceMs = 30_000 } = {}) {
  let draining = false;
  let forceAt = null;
  let inFlight = 0;
  const waiters = [];
  const events = [];

  function maybeResolve() {
    if (inFlight === 0) {
      for (const w of waiters.splice(0)) w({ ok: true, reason: DRAINED });
    }
  }

  function begin() {
    if (draining) return;
    draining = true;
    forceAt = now() + graceMs;
    events.push("begin");
  }

  function wrap(work) {
    if (draining) {
      events.push("refuse");
      return Promise.reject(Object.assign(new Error(REFUSED), { code: REFUSED }));
    }
    inFlight += 1;
    events.push("accept");
    return Promise.resolve()
      .then(work)
      .finally(() => {
        inFlight -= 1;
        maybeResolve();
      });
  }

  function wait() {
    if (!draining) throw new Error("wait_before_begin");
    if (inFlight === 0) return Promise.resolve({ ok: true, reason: DRAINED });
    if (forceAt !== null && now() >= forceAt) {
      events.push("force");
      return Promise.resolve({ ok: false, reason: FORCED, inFlight });
    }
    return new Promise((resolve) => waiters.push(resolve));
  }

  function tickForce() {
    if (!draining || forceAt === null || now() < forceAt) return null;
    if (waiters.length === 0 && inFlight === 0) {
      return { ok: true, reason: DRAINED };
    }
    events.push("force");
    const leftover = inFlight;
    for (const w of waiters.splice(0)) {
      w({ ok: false, reason: FORCED, inFlight: leftover });
    }
    return { ok: false, reason: FORCED, inFlight: leftover };
  }

  return { begin, wrap, wait, tickForce, isDraining: () => draining, inFlight: () => inFlight, events: () => events.slice() };
}

Production wires begin to process.on("SIGTERM"), wrap around the request listener, wait to server.close()'s callback, and tickForce to closeAllConnections(). The pad exists so you can fail the contracts in 20 seconds without standing up kubelet.

Which four contracts do you have to show?

Contract 1: a request accepted before SIGTERM still completes. New work after begin is refused. Event order is accept, begin, refuse.

const clock = { t: 0 };
const gate = createShutdownGate({ now: () => clock.t, graceMs: 30_000 });

const slow = gate.wrap(
  () => new Promise((resolve) => setImmediate(() => resolve("ok-inflight"))),
);
gate.begin();
assert.equal(gate.inFlight(), 1);
await assert.rejects(() => gate.wrap(async () => "should-not-run"), { code: REFUSED });
assert.equal((await gate.wait()).reason, DRAINED);
assert.equal(await slow, "ok-inflight");
assert.deepEqual(gate.events(), ["accept", "begin", "refuse"]);

That is the whole drain. If you cannot show this, you do not have graceful shutdown. You have a signal handler that prints a log line.

Contract 2: process.exit on the first tick drops the in-flight request. The work never settles. The process is gone anyway.

function createNaiveExit() {
  const events = [];
  return {
    wrap: (work) => {
      events.push("accept");
      return Promise.resolve().then(work);
    },
    exitNow: () => {
      events.push("exit");
      return { ok: false, reason: "dropped" };
    },
    events: () => events.slice(),
  };
}

const naive = createNaiveExit();
naive.wrap(() => new Promise(() => {})); // still on the wire
assert.equal(naive.exitNow().reason, "dropped");

This is the rolling-deploy 502. The replica coming up is healthy. The replica going down reset a connection the load balancer already handed it.

Contract 3: a request that outlives the grace period is forced. inFlight stays 1. SIGKILL does not wait for your await.

clock.t = 0;
const late = createShutdownGate({ now: () => clock.t, graceMs: 30_000 });
late.wrap(() => new Promise(() => {}));
late.begin();
clock.t = 30_000;
const forced = late.tickForce();
assert.equal(forced.reason, FORCED);
assert.equal(forced.inFlight, 1);

The spoken version: I would not pretend a 2-minute export fits in 30 seconds. Either I fail that request with 503 on SIGTERM and let the client retry another replica, or I raise terminationGracePeriodSeconds to a number I measured. I would not sit in close() and hope kubelet is patient.

Contract 4: preStop spends the same budget. At t=10_000 the force window has not opened. At t=29_999 it still has not. At t=30_000 an idle drain is allowed to finish. There is no bonus 30.

clock.t = 0;
const prestop = createShutdownGate({ now: () => clock.t, graceMs: 30_000 });
prestop.begin();
clock.t = 10_000;
assert.equal(prestop.tickForce(), null);
clock.t = 29_999;
assert.equal(prestop.tickForce(), null);
clock.t = 30_000;
assert.equal(prestop.tickForce().reason, DRAINED);

The Kubernetes docs even give a 2-second one-off extension if preStop is still running when the grace period expires. That is kubelet covering the hook, not extra drain time for your HTTP server. If the hook sleeps 25 seconds, you have about 5 seconds of SIGTERM left. I have seen a preStop: sleep 20 copied from a nginx snippet into a Node service. Then people wonder why in-flight GraphQL requests reset during every rollout.

I ran those four with node sigterm-drain.mjs. All green.

What do you say out loud in the backend / SRE round?

Something like:

I treat SIGTERM as a drain, not an exit. First I stop being a Service endpoint: fail readiness, then server.close() so we do not accept new TCP. In-flight requests keep running. I wait on a counter, not on a sleep(30). If the counter hits zero I exit 0. If the grace period is about to expire I call closeAllConnections(), log how many were still open, and exit. preStop time is subtracted from the same 30 seconds, so I would not sleep in the hook. TERM has to reach PID 1. If the container PID 1 is a shell that does not forward signals, none of this runs and kubelet SIGKILLs a process that never knew it was dying.

The AceRound DevOps engineer interview guide puts rolling deploys and probe failures in the production-scenario bucket. aceround.app — AI interview assistant is useful when the next hour is talking through the 30-second window while someone interrupts you. It does not replace running the four contracts above.

A few follow-ups I would expect:

Follow-up	What I would not say
Can't we just raise the grace period to 300?	"Then we never have to drain." Long grace periods make rollouts slow. Measure p99 in-flight duration, set grace to that plus a buffer, still refuse new work immediately.
What about HTTP/2 or WebSockets?	`closeAllConnections()` does not destroy upgraded sockets. Those need their own shutdown. I would say so instead of waving `server.close()`.
Why fail readiness before SIGTERM?	Because EndpointSlice removal is not instantaneous. A `preStop` that only sleeps, with no readiness fail, still takes traffic for part of the window. Fail the probe first.
`process.on("SIGTERM", () => process.exit(0))`?	That uninstalls Node's default handler and then exits anyway. Same dropped request, extra confidence.

I would not ship this Map as the process manager. Production is http.Server plus a readiness flag plus a deadline timer. The pad exists so you can fail “new work after SIGTERM” in 20 seconds instead of drawing a rectangle labelled “graceful” on a whiteboard.

FAQ

Does server.close() wait for in-flight requests?

It stops new connections and, since Node 19, idle keep-alive. Active requests keep running until they end or you call closeAllConnections().

Is SIGTERM the same on Windows?

Node can listen for 'SIGTERM' on Windows. Kubernetes Linux nodes send TERM to PID 1. Do not demo this with Ctrl+C and assume it is the same path. Ctrl+C is SIGINT.

Why 30 seconds?

That is the Pod API default when terminationGracePeriodSeconds is nil. kubectl delete uses the same default. You can set it. You cannot ignore SIGKILL after it.

If my handler never calls process.exit, what happens?

Node no longer exits on SIGTERM once a listener exists. You sit in Terminating until kubelet SIGKILLs you at second 30. The log line that says “received SIGTERM” is not a shutdown.

Should the drain reject new HTTP with 503 or just close the listen socket?

Both. Close the listen socket so the kernel refuses new TCP. Return 503 for anything already accepted that you choose not to run. Clients retry the next replica.

If you already handle SIGTERM in production, does the handler wait for inFlight === 0, or does it process.exit on the first tick?

Drafted with AI assistance, then edited. The Node contracts were run locally before publishing. Grace period default of 30 seconds and TERM-then-KILL: Kubernetes Pod lifecycle and the Pod API. server.close / closeIdleConnections / closeAllConnections: Node.js HTTP docs, including the v19.0.0 idle-connection change. SIGTERM listener replacing the default exit: Node.js process signal events.

Fencing Tokens Stop the Write Your Redis Lease Already Released

Karuha — Tue, 01 Sep 2026 09:47:31 +0000

A Redis SET NX PX lock is a lease. It is not mutual exclusion. If the holder pauses longer than the TTL, a second client acquires the same key, writes, and the first client still writes when it wakes up. The fix is a fencing token: a number that only goes up, checked by storage, not by lease.isHeld().

Google autocomplete for fencing token currently suggests pattern, redis, lock, zookeeper, etcd, and redlock. redis distributed lock fills in with Java, Python, Go, C#, Spring Boot. People are searching the primitive by name. The interview is whether you know the lease is not the safety boundary.

What is the interviewer actually asking?

Most whiteboard answers stop at Redis:

SET lock:acct:1 <random> NX PX 30000

That is the pattern Redis itself documents on the SET command page: create the key only if it is missing, auto-release with an expiry, unlock with a Lua compare-and-delete so you do not DEL someone else's lease. Fine for efficiency. Martin Kleppmann's 2016 note on distributed locking splits the use cases in one paragraph. If two nodes do the same work and you pay AWS five extra cents, a best-effort lock is enough. If two nodes debit the same account, you need correctness. SET NX does not give you that.

The failure is not exotic. Kleppmann's diagram is the whole interview: client A gets token 33, pauses (GC, a page fault, a SIGSTOP, a delayed packet), the lease expires, client B gets token 34 and writes. A resumes and writes with 33. Storage that only checks "did you once hold a lock?" accepts both.

I ran that sequence in 70 lines of Node with an injected clock. No Redis process. The clock is the point.

Why doesn't checking the lease just before the write save you?

Because the pause can happen after the check. Kleppmann is blunt about this: you cannot insert if (!lock.expired) write() and call it fixed. GC can stop the thread between the last check and the write. A packet can sit in the network for a long time after you sent it. He cites a GitHub incident where packets were delayed about 90 seconds. Your isHeld() returned true. The write arrived after B already committed.

So the resource has to be the one that says no. The lock service only issues a strictly increasing token. Storage remembers the highest token it accepted and rejects anything that went backwards.

ZooKeeper people already have this: zxid or the znode version. etcd has revision. Redis SET NX returns OK or nil. It does not return a monotonic fence. That is Kleppmann's actual objection to Redlock as a correctness lock, not a dunk on Redis.

How small is the pad version?

Two objects. A lease map that mints a fence on every successful acquire. An account that optionally enforces token > lastFence on every debit. Clock and TTL are injected so the tests do not sleep.

const STALE = "stale_fence";
const HELD = "lock_held";

function createLeaseLock({ now, ttlMs = 30 } = {}) {
  const locks = new Map();
  let nextFence = 33; // Kleppmann's diagram

  function acquire(key, owner) {
    const current = locks.get(key);
    if (current && current.expiresAt > now()) {
      return { ok: false, error: HELD, holder: current.owner };
    }
    const fence = nextFence++;
    locks.set(key, { owner, fence, expiresAt: now() + ttlMs });
    return { ok: true, fence };
  }

  function isHeld(key, owner) {
    const current = locks.get(key);
    return Boolean(current && current.owner === owner && current.expiresAt > now());
  }

  return { acquire, isHeld };
}

function createAccount({ fence = true } = {}) {
  let balance = 100;
  let lastFence = 0;
  const writes = [];

  function debit(amount, token) {
    if (fence && !(token > lastFence)) {
      return { ok: false, error: STALE, lastFence, token };
    }
    if (fence) lastFence = token;
    balance -= amount;
    writes.push({ amount, token, balance });
    return { ok: true, balance };
  }

  return { debit, getBalance: () => balance, getLastFence: () => lastFence, writes };
}

The starting fence is 33 so the narration matches the blog post you should actually cite. Production would start at 1. I do not care.

Which six contracts do you have to show?

Contract 1: while the lease is live, B cannot acquire. This is the NX part. If you cannot show this, you do not have a lock at all.

const clock = { t: 0 };
const lock = createLeaseLock({ now: () => clock.t, ttlMs: 30 });
const a = lock.acquire("acct:1", "A");
const b = lock.acquire("acct:1", "B");
assert.equal(a.ok, true);
assert.equal(a.fence, 33);
assert.equal(b.ok, false);

Contract 2: TTL is a liveness feature. After 31ms, A is not the holder. B acquires. The new fence is 34, strictly greater.

clock.t = 31;
const b2 = lock.acquire("acct:1", "B");
assert.equal(lock.isHeld("acct:1", "A"), false);
assert.equal(b2.fence, 34);

Redis documents this as a liveness property: even if the client crashes, the key expires. That is the part people remember. The next contract is the part they skip.

Contract 3: turn fencing off. Same pause. B debits 10 with token 34. A wakes up and debits 10 with token 33. Both succeed. Balance is 80. Last write is token 33. You just lost B's update, or you double-charged the account, depending how you read the ledger.

const unfenced = createAccount({ fence: false });
unfenced.debit(10, 34);
assert.equal(unfenced.debit(10, 33).ok, true);
assert.equal(unfenced.getBalance(), 80);

That is the broken writeData in Kleppmann's post, executable.

Contract 4: same sequence, fencing on. B's debit is accepted. A's debit returns stale_fence. Balance stays 90. lastFence is 34.

const fenced = createAccount({ fence: true });
const lock2 = createLeaseLock({ now: () => clock.t, ttlMs: 30 });
clock.t = 0;
const aLease = lock2.acquire("acct:1", "A");
clock.t = 31;
const bLease = lock2.acquire("acct:1", "B");
assert.equal(fenced.debit(10, bLease.fence).ok, true);
assert.equal(fenced.debit(10, aLease.fence).error, STALE);
assert.equal(fenced.getBalance(), 90);

Contract 5: equal token is stale. > not >=. A retry of the same successful write should be idempotent at the business layer (same debit id), not by sending the same fence again as a second debit.

assert.equal(fenced.debit(5, 40).ok, true);
assert.equal(fenced.debit(5, 40).error, STALE);

Contract 6: the TOCTOU the interviewer will poke. A checks isHeld at t=0. Clock jumps to 31. B acquires and writes. A then writes with the old fence. Fencing still rejects it. The check was theater.

assert.equal(lock.isHeld("acct:1", "A"), true);
clock.t = 31;
// B writes, A writes. Only B's token survives.

I ran those six with node fencing-token.mjs. All green.

What do you say out loud in the system-design round?

Something like:

I would ask whether the lock is for efficiency or correctness. For a cache fill, SET NX PX on one Redis is enough and I would say so. For an account debit I would not trust the lease. The lock service returns a monotonically increasing fencing token. Every write to the resource carries that token. The resource rejects anything less than or equal to the highest token it has already accepted. The check lives in the UPDATE ... WHERE last_fence < $token (or the equivalent compare-and-set). A client-side if (lease.isValid()) is not the check.

If they say "we use Redlock," I would not pick a fight with Redis's page. I would say: Redlock still does not hand me a fence. Without a fence, a paused holder can still write after a new holder has written. For correctness I want ZooKeeper/etcd (zxid / revision) or a database unique constraint plus a generation column. Redis is fine as an efficiency lock.

The backend round that asks "how do you lock this?" is the same round as outbox, idempotency keys, and the 3 AM CPU spike. The AceRound backend-developer interview guide puts those in the production-scenario bucket. aceround.app — AI interview assistant is useful when the next hour is talking through the pause while someone interrupts you. It does not replace running the six contracts above.

A few follow-ups I would expect:

Follow-up	What I would not say
Can't we just heartbeat and extend the TTL?	"Then the pause cannot happen." Heartbeats help a healthy holder. They do not fence a write that is already in flight after the lease died.
Redis `GET` the lock just before `SET` the account?	That is two round trips and still a race. The account write has to be conditional on the fence in one atomic step.
UUID as the token?	UUIDs do not order. Storage cannot tell 33 from 34. Monotonic is the whole trick.
What about Redlock's five nodes?	Majority voting is about the lock service surviving a Redis crash. It still does not produce a fence. Kleppmann's critique starts there.

I would not ship this Map. Production needs the fence on the resource that can actually lose money, persisted, compared atomically. The pad exists so you can fail the stale debit in 20 seconds instead of drawing a mutex on a whiteboard.

FAQ

Is a fencing token the same as an idempotency key?

No. An idempotency key says "this client intent runs once." A fencing token says "this generation of the lock is allowed to write, older generations are not." You usually want both. The debit should have an idempotency key so B's retry does not debit twice, and a fence so A's delayed packet cannot debit after B.

Does every lock need this?

No. Kleppmann's efficiency case is real. Singleflight for a cache stampede, a rate-limit counter, a "don't send the same email twice if we can help it" lock: lose one and you are annoyed. Do not pay ZooKeeper for that.

Why start the demo at 33?

So the story matches the diagram in the 2016 post. Interviewers who have read it will nod. If they have not, 1 and 2 work the same.

Can the storage service skip the check if the client promises it still holds the lock?

That is the broken code sample. The client is the one that paused. Storage is the only place the side effect becomes true.

If you already use Redis locks in production, does the resource you protect compare a fence, or does it trust SET NX?

Drafted with AI assistance, then edited. The Node contracts were run locally before publishing. Lease vs mutex, token 33 vs 34, and the "check before write" hole: Kleppmann, 8 Feb 2016. SET key value NX EX|PX: Redis SET. Redlock's safety/liveness list: Distributed locks with Redis.

Why JWT Refresh Token Rotation Fails Without a Token Family

Karuha — Mon, 31 Aug 2026 14:22:12 +0000

JWT refresh token rotation is not "issue a new token and delete the old one." RFC 9700 says you keep the relationship. If a spent token shows up again, you revoke the whole family. I ran that contract in 80 lines of Node. Rotation without reuse detection still hands the session to whoever got there second.

Google autocomplete for jwt refresh token rotation currently suggests meaning, header, Stripe, example, generator, and pattern. People are searching the mechanism by name, not "auth in general."

What do interviewers actually want when they say "rotate the refresh token"?

A common whiteboard answer is: access token lives 15 minutes, refresh token lives 30 days, each refresh mints a new access token. That is a session, not rotation.

RFC 9700 section 4.14 is the current OAuth 2.0 security BCP (January 2025). For public clients it requires one of two things: sender-constrained refresh tokens (DPoP / mTLS), or rotation. Rotation is defined as:

issue a new refresh token on every access-token refresh
invalidate the previous one
retain the relationship
if a later request presents the invalidated token, revoke the active one

The last two bullets are the interview. Delete-on-use with no memory of the parent grant is just a shorter-lived secret. The attacker who wins the race keeps working. The legitimate client gets invalid_grant and you never find out why.

Auth0's public docs call the retained relationship a token family and the alarm "automatic reuse detection." Their example is the one I use in loops: legitimate client holds RT1, it leaks, legitimate client exchanges RT1 for RT2, attacker replays RT1, the family including RT2 dies, everyone re-authenticates. The log event they name is ferrt.

I am not reimplementing Auth0. I wanted a store I can run in the pad with node:assert/strict and then narrate.

Why does deleting the old token fail the theft case?

Three records. That is the whole model.

{
  token,       // opaque string the client holds
  familyId,    // the grant / lineage
  generation,  // 0, 1, 2...
  spentAt,     // null while this row is current
  replacement, // the token issued when this row was spent
}

Spent is not deleted. If you Map.delete(rt1) after minting RT2, a replay of RT1 looks identical to a typo: invalid_grant. You cannot tell theft from a stale client. You also cannot revoke RT2, because you no longer know they are siblings.

The store below is dependency-free. Clock and leeway are injected so the tests do not sleep.

import { randomBytes } from "node:crypto";

const REUSE = "refresh_token_reused";
const UNKNOWN = "invalid_grant";
const FAMILY_REVOKED = "family_revoked";

function createStore({ now = () => Date.now(), leewayMs = 2000 } = {}) {
  const byToken = new Map();
  const families = new Map();

  function mint(familyId, generation) {
    const token = randomBytes(16).toString("hex");
    const record = { token, familyId, generation, spentAt: null, replacement: null };
    byToken.set(token, record);
    const family = families.get(familyId);
    family.current = token;
    family.lineage.push(token);
    return record;
  }

  function issue(userId) {
    const familyId = randomBytes(8).toString("hex");
    families.set(familyId, { userId, current: null, lineage: [], revoked: false });
    return mint(familyId, 0);
  }

  function rotate(presented) {
    const record = byToken.get(presented);
    if (!record) return { ok: false, error: UNKNOWN };

    const family = families.get(record.familyId);
    if (family.revoked) return { ok: false, error: FAMILY_REVOKED };

    if (record.token === family.current) {
      record.spentAt = now();
      const next = mint(record.familyId, record.generation + 1);
      record.replacement = next.token;
      return { ok: true, token: next.token, generation: next.generation };
    }

    const isImmediatePrevious =
      record.replacement != null && record.replacement === family.current;
    if (isImmediatePrevious && now() - record.spentAt <= leewayMs) {
      const current = byToken.get(family.current);
      return { ok: true, token: current.token, generation: current.generation, retry: true };
    }

    family.revoked = true;
    family.current = null;
    return { ok: false, error: REUSE };
  }

  return { issue, rotate };
}

Which five contracts do you have to show?

Contract 1: happy path. RT1 in, RT2 out, different string, generation 1.

const store = createStore();
const rt1 = store.issue("u1");
const r2 = store.rotate(rt1.token);
assert.equal(r2.ok, true);
assert.equal(r2.generation, 1);
assert.notEqual(r2.token, rt1.token);

Contract 2: rotate twice, then replay RT1. RT1 is no longer the immediate previous, so this is reuse, not a retry. The family dies. RT3, which the legitimate client is holding, must also fail.

const r3 = store.rotate(r2.token);
assert.equal(store.rotate(rt1.token).error, REUSE);
assert.equal(store.rotate(r3.token).error, FAMILY_REVOKED);

That is the RFC 9700 sentence in executable form: the server "cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token."

Contract 3: flaky network. Auth0's dashboard calls this the rotation overlap period, in seconds. A mobile client sends RT1, loses the response, retries RT1 500ms later. If you treat that as theft, you lock out real users. The demo uses 2000ms so the test can move a fake clock.

const clock = { t: 0 };
const retryStore = createStore({ now: () => clock.t, leewayMs: 2000 });
const a1 = retryStore.issue("u2");
const a2 = retryStore.rotate(a1.token);
clock.t = 500;
const retry = retryStore.rotate(a1.token);
assert.equal(retry.retry, true);
assert.equal(retry.token, a2.token); // same RT2, not a new generation

Contract 4: same retry after the window. 2501ms later, RT1 is theft. Family gone.

clock.t = 2501;
assert.equal(retryStore.rotate(a1.token).error, REUSE);

Auth0's support note on leeway is stricter than "any spent token may retry." Only the previous generation is inside the window. The generation before that still kills the family, even if the clock says you are inside N seconds. Contract 2 already covers that: RT1 after RT1→RT2→RT3 is older than previous.

Contract 5: attacker spends RT1 first. Advance the clock past leeway, then the legitimate client presents RT1. Same alarm. The attacker's RT2 dies too. I ran this with an injected clock at t=0 then t=2501. If you skip the clock and default Date.now(), the second call lands inside 2 seconds and looks like a retry. That is a real production footgun, not a test smell.

Unknown tokens stay invalid_grant. Do not revoke some other user's family because of a random string.

I ran those eight assertions (happy path, double-rotate replay, post-revoke current, retry inside window, retry after window, attacker-first plus family kill, unknown token) with node rt-rotation.mjs. All green.

What do you say out loud in the 45-minute backend round?

Something like:

I would keep refresh tokens one-time. I would not delete the spent row. Replay of a spent token is reuse detection: revoke the family, force a new grant. Retry of the immediate previous token inside a short overlap is a lost response, not theft. RFC 9700 also allows DPoP instead of rotation. I picked rotation because the pad is an in-memory map. Production still needs idle expiry.

That speech is the score. The map is evidence.

A few follow-ups I would expect, and the short answers:

Follow-up	What I would not say
Why not put the family id inside a signed JWT refresh token?	"Because JWTs cannot be revoked." They can, you still need a denylist or a family row. Encoding the grant id in the token is an RFC 9700 implementation note, not a substitute for the store.
How long is access token vs refresh token?	Numbers without rotation are trivia. 5–60 minutes for access is common. Refresh idle expiry is the SHOULD in 4.14.2. Pick a number and say it is policy, not physics.
SPA / localStorage?	Auth0's rotation doc exists partly because ITP broke silent iframe cookie refresh. Rotation is the remediation they document. I still would not keep a refresh token in `localStorage` if I have an HttpOnly cookie option.
Stripe Idempotency-Key vs this?	Different object. Idempotency keys dedupe a POST. Token families detect two holders of one secret. I already shipped a Node idempotency guard in July; this is the sibling question.

The backend interview that asks "JWT vs session cookies, OAuth flows, idempotency keys" is the same round. The AceRound backend-developer interview guide lists those as the REST/architecture bucket, sitting next to the 3 AM CPU production scenario. Rotation is one concrete artifact from that bucket. aceround.app — AI interview assistant is useful when the next hour is verbal walkthrough under interruption. It does not replace running the five contracts above.

What this is not

It is not "never use JWT." Access tokens can stay JWT. The refresh token in this pad version is an opaque random 16 bytes on purpose. Mixing "stateless JWT" with "I need to revoke a family" is how people invent a denylist and then claim they are stateless.

It is not a license to skip sender-constrained tokens. RFC 9700 lists rotation or DPoP/mTLS for public clients. If the interviewer is on a native app with a secure enclave, DPoP is the stronger answer and you should say so.

I would not ship this Map. Production needs a row per token, a unique constraint on the current token, and the rotate-and-revoke in one transaction. The pad version exists so you can fail the replay case in 30 seconds.

FAQ

Is reuse detection the same as token rotation?

No. Rotation makes the secret one-time. Reuse detection is the alarm when a one-time secret is presented twice. Skip the alarm and the attacker who exchanged first keeps a valid RT2.

Why kill RT2, which the legitimate user is holding?

Because the server cannot tell who is the thief. RFC 9700 is explicit: stop the attack at the cost of a fresh grant. The legitimate user signs in again. The attacker does not keep a quiet session.

How long should the overlap window be?

Auth0 configures it in seconds. Too long and you widen the replay margin. Too short and a lost mobile response locks the user out. I would start at a few seconds, log ferrt-style events, and tune from false-positive rate, not from a blog number.

Do confidential server clients still need this?

RFC 6749 already binds refresh tokens to the client that received them. 9700 still recommends rotation as an extra measure. For public clients (SPA, native) it is a MUST: rotation or sender-constrained.

If you already rotate refresh tokens in production, does a replay of generation N-2 revoke the family, or does it just return invalid_grant?

Drafted with AI assistance, then edited. The Node contracts were run locally before publishing. Rotation + reuse detection: Auth0 docs. Public-client MUST: RFC 9700 §4.14.2. Overlap / previous-generation only: Auth0 support on leeway.

Google's AI-Assisted Coding Interview: Catch the Cached 503 the Model Will Ship

Karuha — Sun, 30 Aug 2026 13:17:50 +0000

Google's 2026 AI-assisted coding interview does not grade a green test run. The new code-comprehension round scores whether you reject a patch that compiles. I planted a sticky 503 in a promise cache. The model's first fix still shipped the outage.

I have not sat the Google pilot. I'm going off Business Insider's May 7 reporting and Google's own April 22 Cloud Next note. The drill below is what I would run the night before a sanctioned AI-assisted loop, not a stealth overlay for a round that still bans tools.

What does Google's AI-assisted coding interview actually score?

Business Insider reviewed an internal document and got a Google spokesperson on the record. Starting in the second half of 2026, junior and mid-level software roles on selected US teams (Cloud, plus platforms and devices) get an approved assistant during a code comprehension round. The assistant in the pilot is Gemini. Candidates are expected to read, debug, and optimize an existing codebase. Interviewers score "AI fluency": prompt engineering, output validation, and debugging.

Brian Ong, Google's VP of recruiting, told BI the pilot exists "to be more reflective of how our teams are operating in the AI era."

That maps to a number Google already published. On April 22, 2026, Sundar Pichai wrote that 75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall. If three quarters of the diff is model-authored, the interview that still asks you to invert a binary tree from a blank buffer is testing a job that is shrinking.

The document's phrase is "human-led, AI-assisted." You own the hypothesis. Gemini types. You decide whether the types were allowed to land.

This is not unique to Google. CoderPad's October 30, 2025 writeup of Meta's pilot quotes Meta recruiting saying it is not cheating, it is how the job is evolving. BI also names Canva and Cognition as companies that already let candidates use AI in technical interviews. Google search autocomplete for ai assisted coding interview currently suggests Meta, Microsoft, Canva, prep, mock, and reddit as follow-on queries. People are searching the format by name.

If your loop does not say AI is allowed, none of this is permission to sneak a second window onto a shared screen. The sanctioned round and the stealth overlay are opposite products. Mixing them up is how people get offers pulled.

Why does caching the in-flight promise look correct?

Here is the kind of 40-line module I would expect in a code-comprehension pad. It looks like a reasonable answer to "don't stampede the origin."

const cache = new Map();

async function fetchJsonCached(url, fetcher) {
  if (cache.has(url)) return cache.get(url);

  const pending = fetcher(url).then(async (res) => {
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res.json();
  });

  cache.set(url, pending);
  return pending;
}

Two parallel /user reads hit fetcher once. That part is right. The bug is the rejected promise staying in the Map. A single 503 becomes the answer forever.

I asked a model to "fix the cache so a 503 does not break later requests." The first patch looked like this:

async function fetchJsonCached(url, fetcher) {
  try {
    if (cache.has(url)) return cache.get(url);
    const pending = fetcher(url).then((res) => res.json());
    cache.set(url, pending);
    return pending;
  } catch {
    return { error: true };
  }
}

Three mistakes, all the kind that still compile:

The try/catch does not wrap the awaited promise, so it never sees the 503.
res.ok is gone, so a 503 body gets parsed as success JSON.
The 503 payload is still sticky in the Map. The next call never reaches the network.

That is the failure mode the round is built to catch. The model optimized for "don't throw." The interviewer is scoring "don't poison the cache."

How do you prove the 503 is still sticky?

Do not argue with the model. Replay the outage.

function sequenceFetcher(responses) {
  let i = 0;
  let calls = 0;
  const fetcher = async () => {
    calls += 1;
    const next = responses[Math.min(i, responses.length - 1)];
    i += 1;
    return next;
  };
  return { fetcher, getCalls: () => calls };
}

function jsonRes(status, body) {
  return {
    ok: status >= 200 && status < 300,
    status,
    json: async () => body,
  };
}

Contract 1, buggy module: first call 503, second call should have been 200.

const seq = sequenceFetcher([
  jsonRes(503, { error: "upstream" }),
  jsonRes(200, { id: 7 }),
]);

await fetchJsonCached("/user", seq.fetcher); // throws HTTP 503
await fetchJsonCached("/user", seq.fetcher); // throws HTTP 503 again
seq.getCalls(); // 1. The origin never got a second chance.

Contract 2, the model's patch: even worse, because it returns { error: "upstream" } as if it were a user record. getCalls() is still 1.

The actual one-line repair is not a retry library. Delete the entry when the promise rejects, then let the next caller start a new in-flight promise.

const pending = fetcher(url)
  .then(async (res) => {
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res.json();
  })
  .catch((err) => {
    cache.delete(url);
    throw err;
  });

cache.set(url, pending);
return pending;

Contract 3, after the delete: first call still throws 503. Second call returns { id: 7 }. getCalls() is 2.

Contract 4, still required: two parallel first calls coalesce. getCalls() stays 1 on a 200. You are not allowed to "fix" the 503 by removing in-flight dedupe. Interviewers notice when you swing from one bug to the stampede.

I ran those four plus the model's sticky-body case as a local Node script, no dependencies, node:assert/strict. Five contracts, all green on the delete-on-reject version.

What should you say out loud while Gemini is typing?

The round is 60 minutes of shared editing. Silence while you wait on a stream is the other way to fail. Narrate the contract before you accept the diff.

I would say, roughly:

I would cache the in-flight promise so two mounts don't double-fetch. I would not cache a rejection. If Gemini's patch drops res.ok or wraps this in an empty catch, I want a replay: 503 then 200. If the second call never hits the fetcher, we reject the diff.

That speech is the score. The code is evidence.

A few other tells I would look for in whatever module they hand you, same 10-minute budget:

Smell in the model's patch	What you replay
Empty `catch` / `return null`	The error path now looks like success
Cache written before `res.ok`	4xx/5xx bodies become canonical JSON
TTL added, rejection kept	You paid for expiry and still serve the 503 for the whole window
Lock around the wrong key	Concurrent URLs share one poisoned slot
Tests only cover the 200	Add the 503-then-200 case yourself

None of those need a framework. They need you to keep a failing fixture in the pad and refuse to delete it.

What this format is not

It is not "the interviewer wants to watch you prompt." Prompt quality is one of three bullets in Google's fluency rubric, sitting next to output validation and debugging. A candidate who pastes the whole file into Gemini and then reads the answer aloud is doing the opposite of "human-led."

It is also not a license for every company. Meta's CoderPad pilot is opt-in and still rolling. Google's is a 2026 pilot on selected US teams. If the scheduler, the recruiter, or the pad header does not say an assistant is in the environment, assume it is not.

The prep that transfers across both the Google comprehension round and Meta's AI-enabled pad is the same muscle: take an unfamiliar repo, keep a failing fixture, and treat the model as a junior who ships the first compile.

I use aceround.app — AI interview assistant when the next round is verbal (system design, "walk me through this diff") and I need to rehearse the explanation under interruption. It does not replace the Node replay above. If you cannot show the 503-then-200 contract in the pad, the spoken version will not save you.

FAQ

Does Google let every candidate use Gemini in the coding round?

No. BI describes a second-half 2026 pilot for junior and mid-level roles on selected US teams, with Gemini as the approved assistant. Do not assume your loop is in that cohort until someone says so.

If the tests pass after I accept Gemini's patch, am I done?

Not if the tests never sent a 503. Add that case. A green suite that only covers 200 is how the sticky cache ships.

Is this the same skill as "turn the model's answer into unit tests"?

Related, different fixture. That version starts from a blank solution. This version starts from a repo that already almost works. Google's comprehension round is the second one.

Should I still practice LeetCode?

Yes, for loops that still ban AI. For loops that allow it, spend equal time reading someone else's 200-line module and listing the contracts you would refuse to drop.

What 503-then-200 fixture would you add to the last model patch you accepted at work?

Drafted with AI assistance, then edited. The Node contracts were run locally before publishing. Google pilot details: Business Insider, May 7, 2026. 75% figure: Pichai, April 22, 2026. Meta pilot: CoderPad, October 30, 2025.

Transactional Outbox in Node.js: Never Publish Outside the Transaction

Karuha — Sat, 29 Aug 2026 07:27:58 +0000

If you INSERT an order and then publish to Kafka, you have two systems and a crash window, not an atomic write. A transactional outbox stores the event in the same database transaction as the order. Delivery is a later, retryable job. That is the interview answer.

I treat this as a Node.js drill. Five assertions. If one of them is hand-wavy, the answer is not ready.

What is the interviewer actually asking?

"How do you publish an event when an order is created?" is a trap if you stop at await kafka.send(...).

They want you to name the dual-write problem. Confluent's write-up is the cleanest public version: you must update two independent systems, a database and a broker, and a failure between those two writes leaves them inconsistent. Reverse the order and you just swap "lost event" for "phantom event." Wrap the Kafka call in a database transaction and it still does not roll back the message that already left the process.

The follow-up is always the same: without two-phase commit.

Microsoft's Cosmos DB guidance says the same thing in vendor language: save the business object and its events in one transaction, then let a separate worker publish. The request path stops owning the broker.

How does a dual-write fail in code?

The store below is an in-memory stand-in for Postgres. begin / commit / rollback copy the maps. That is enough to make the crash window visible.

class Store {
  constructor() {
    this.orders = new Map();
    this.outbox = [];
    this.nextId = 1;
    this.tx = null;
  }
  begin() {
    this.tx = {
      orders: new Map(this.orders),
      outbox: this.outbox.map((row) => ({ ...row })),
      nextId: this.nextId,
    };
  }
  commit() {
    this.orders = this.tx.orders;
    this.outbox = this.tx.outbox;
    this.nextId = this.tx.nextId;
    this.tx = null;
  }
  rollback() {
    this.tx = null;
  }
  view() {
    return this.tx ?? this;
  }
  insertOrder(payload) {
    const id = String(this.view().nextId++);
    this.view().orders.set(id, { id, ...payload });
    return id;
  }
  insertOutbox(event) {
    this.view().outbox.push({
      id: event.id,
      type: event.type,
      payload: event.payload,
      published: false,
      lockedBy: null,
    });
  }
}

Naive create: commit the order, then publish. Crash after commit.

function dualWriteCreateOrder(store, broker, { crashAfterCommit }) {
  store.begin();
  const orderId = store.insertOrder({ sku: "SKU-1", qty: 1 });
  store.commit();
  if (crashAfterCommit) return { orderId, published: false };
  broker.publish({ id: `order-${orderId}`, type: "order.created", orderId });
  return { orderId, published: true };
}

Assertion one: the order row exists, the broker is empty. That is a lost order.created. Shipping never starts. Support gets a ticket that looks like a "Kafka issue."

Flip the order of operations and you get the other inconsistency.

function phantomPublishThenRollback(store, broker) {
  store.begin();
  const orderId = store.insertOrder({ sku: "SKU-1", qty: 1 });
  broker.publish({ id: `order-${orderId}`, type: "order.created", orderId });
  store.rollback();
  return orderId;
}

Assertion two: the order is gone, the broker still has the event. Downstream just charged a card for a row that never committed.

Retries do not close this. An in-memory retry dies with the process. A durable retry is another write, which is the original problem again. Confluent walks through both anti-patterns; I will not pretend a try/catch around kafka.send is a design.

How do you commit the event with the order?

Write both rows in one transaction. Do not talk to the broker on the request path.

function outboxCreateOrder(store, payload) {
  store.begin();
  const orderId = store.insertOrder(payload);
  store.insertOutbox({
    id: `order-${orderId}`,
    type: "order.created",
    payload: { orderId },
  });
  store.commit();
  return orderId;
}

Assertion three: after create, the order and the outbox row exist, and the broker is still empty. That emptiness is the point. The request returned 201 because Postgres committed, not because Kafka acknowledged.

If create rolls back, both rows vanish together. There is no phantom event to unwind.

How does the relay claim rows without blocking?

A separate process reads unpublished rows and publishes them. Two workers must not take the same row, and they must not sit in a lock-wait queue either.

Postgres documents this as FOR UPDATE SKIP LOCKED. The docs are blunt: skipping locked rows is an inconsistent view of the table, "not suitable for general purpose work," and specifically for "multiple consumers accessing a queue-like table." That sentence is the interview soundbite.

The in-memory version is a locked-by field. Same contract.

function claimSkipLocked(store, workerId, limit) {
  const claimed = [];
  for (const row of store.outbox) {
    if (claimed.length >= limit) break;
    if (row.published || row.lockedBy) continue;
    row.lockedBy = workerId;
    claimed.push(row);
  }
  return claimed;
}

function relay(store, broker, workerId, { failAfterPublish = false } = {}) {
  const claimed = claimSkipLocked(store, workerId, 10);
  for (const row of claimed) {
    broker.publish({ id: row.id, type: row.type, ...row.payload });
    if (failAfterPublish) {
      row.lockedBy = null;
      continue;
    }
    row.published = true;
    row.lockedBy = null;
  }
  return claimed.map((row) => row.id);
}

Assertion four: two workers each claim one of two pending rows. The IDs differ. Nobody blocked.

In real SQL the claim and the status update belong in one statement, usually a CTE SELECT ... FOR UPDATE SKIP LOCKED feeding an UPDATE ... RETURNING. If you SELECT, close the transaction, then UPDATE, you rebuilt the race with extra steps.

CDC (Debezium tailing the WAL) is the other relay. Polling vs CDC is a latency/ops trade-off, not a different guarantee. Both are at-least-once.

Why is the consumer still responsible for duplicates?

Publish, then crash before published = true. The next relay pass publishes the same id again.

function consumeIdempotent(inbox, event, sideEffects) {
  if (inbox.has(event.id)) return "duplicate";
  sideEffects.push(event);
  inbox.add(event.id);
  return "applied";
}

Assertion five: the broker has two copies of the same event id. The inbox applies it once.

That is not a bug in the outbox. Microsoft's Cosmos write-up says the change feed is at-least-once and the consumer dedupes by event id. Same rule on Kafka. If you tell the interviewer "exactly-once," they will ask where the dedupe table lives. Put the inbox write in the same transaction as the side effect, or a crash between "I processed it" and "I recorded that I processed it" duplicates the side effect.

The event id is the idempotency key. Do not hash the payload. Two legitimate order.updated events can look similar.

How do you narrate this in the room?

I use a four-beat answer and stop.

Dual-write: two systems, no shared transaction, crash window either way.
Outbox: event row in the same commit as the order. Request path does not call Kafka.
Relay: poller or CDC. Concurrent workers use SKIP LOCKED, not FOR UPDATE that waits.
Delivery: at-least-once. Idempotent consumer with a durable inbox. Event sourcing or "listen to yourself" if you do not have local transactions.

Trade-offs I expect to be asked:

Latency. The event is not on the broker when the HTTP handler returns. Say "eventual, bounded by poll interval or CDC lag," not "immediate."
Ordering. Publishing by id / insert order preserves causality inside one aggregate. Do not promise global order across partitions.
Retention. Mark published or delete. Deleting shrinks the table; keeping rows helps replay. Either is fine if you can explain vacuum and the unique event id.
When it is overkill. A monolith that sends email inside the request and can tolerate a missed email does not need this. A payment capture that must notify ledger and fraud does.

Once the five assertions pass, the remaining work is saying those trade-offs under follow-up pressure. I rehearse that part with aceround.app — AI interview assistant, because the code is the easy half.

FAQ

Does a transactional outbox give exactly-once delivery?

No. It makes the intent to publish atomic with the business write. The relay is at-least-once. Exactly-once end-to-end is outbox plus an idempotent consumer.

Can I skip the outbox table and use Kafka transactions?

Kafka transactions coordinate produces and offsets inside Kafka. They do not enlist your Postgres INSERT. You still have two systems.

Is SKIP LOCKED enough without idempotency?

No. It stops two live workers from grabbing the same unpublished row. It does not stop a row from being published twice after a crash between publish and ack.

When would you pick CDC over a polling relay?

When you already run Debezium (or Cosmos change feed) and you care about lower lag without hammering SELECT. Polling is the honest default: one extra table, one worker, obvious metrics.

Sources: Confluent on the dual-write problem, Microsoft's Cosmos DB transactional outbox, PostgreSQL SELECT locking / SKIP LOCKED.

Written with AI assistance, then checked against a local Node.js run of the five assertions and the vendor pages above.

Webhook Signature Verification in Node.js: Hash the Raw Bytes

Karuha — Fri, 28 Aug 2026 14:40:03 +0000

A webhook HMAC is not a string compare on parsed JSON. Sign the exact bytes on the wire, put the timestamp inside that HMAC, compare with timingSafeEqual, and reject anything older than five minutes. That is the contract. In a backend interview, the follow-up is why each of those four steps exists.

I treat this as a small Node.js drill, not a slide. Five assertions. If one of them is hand-wavy, the answer is not ready.

What is the interviewer actually asking?

"How do you verify a webhook?" is a trap if you stop at "I check the signature header."

They want a receiver that can prove three things about a public POST endpoint:

the body was not rewritten in transit
the timestamp in the header was not swapped for "now"
a captured valid request cannot be replayed six minutes later

Stripe documents this model directly: the timestamp lives in the Stripe-Signature header, it is part of the signed payload, and the official libraries use a default tolerance of five minutes. Setting that tolerance to 0 does not mean "strict." It disables the recency check.

GitHub's version is slightly thinner. Validating webhook deliveries signs the raw body with HMAC-SHA256 and sends X-Hub-Signature-256: sha256=<hex>. There is no timestamp inside that HMAC, so replay protection is your problem. The Stripe-shaped contract is the more complete interview answer because it forces you to talk about replay.

flowchart LR
  A[Raw body bytes] --> B{HMAC over t.body}
  B -->|match and fresh| C[Accept]
  B -->|mismatch| D[Reject signature]
  B -->|stale timestamp| E[Reject replay]

How do you build the signed payload?

Keep the raw body as a string. Do not JSON.parse it first.

The signed material is timestamp + "." + rawBody. The header looks like t=<unix>,v1=<hex>. During secret rotation you may see more than one v1; accept the request if any of them matches.

import crypto from "node:crypto";

const TOLERANCE_SEC = 300;

function parseSignatureHeader(header) {
  const values = { t: null, v1: [] };
  for (const part of header.split(",")) {
    const eq = part.indexOf("=");
    if (eq < 0) continue;
    const key = part.slice(0, eq).trim();
    const value = part.slice(eq + 1).trim();
    if (key === "t") values.t = value;
    if (key === "v1") values.v1.push(value);
  }
  if (!values.t || values.v1.length === 0) {
    throw new Error("malformed signature header");
  }
  return values;
}

function hmacHex(secret, signedPayload) {
  return crypto
    .createHmac("sha256", secret)
    .update(signedPayload, "utf8")
    .digest("hex");
}

function timingSafeHexEqual(a, b) {
  const left = Buffer.from(a, "hex");
  const right = Buffer.from(b, "hex");
  if (left.length === 0 || left.length !== right.length) return false;
  return crypto.timingSafeEqual(left, right);
}

export function verifyWebhook({
  rawBody,
  header,
  secret,
  nowSec,
  toleranceSec = TOLERANCE_SEC,
}) {
  const { t, v1 } = parseSignatureHeader(header);
  const timestamp = Number(t);
  if (!Number.isInteger(timestamp)) {
    return { ok: false, reason: "timestamp" };
  }

  const expected = hmacHex(secret, `${t}.${rawBody}`);
  const signatureOk = v1.some((candidate) =>
    timingSafeHexEqual(expected, candidate)
  );
  if (!signatureOk) return { ok: false, reason: "signature" };

  if (Math.abs(nowSec - timestamp) > toleranceSec) {
    return { ok: false, reason: "replay" };
  }

  return { ok: true, reason: "accepted" };
}

timingSafeEqual throws if the buffers differ in length. Check length first and return false. For SHA-256 hex that length is public (64 characters), so leaking it is fine. Comparing with === is the version that silently teaches a timing oracle.

Why does JSON.parse break a valid signature?

This is the bug I see in take-home webhooks and in interview sketches.

Express json() middleware parses the body. You then JSON.stringify(req.body) and HMAC that. The provider signed the bytes on the wire, including spaces and the trailing newline. V8 will not put those back.

import assert from "node:assert/strict";

const secret = "whsec_test_secret";
const now = 1_777_000_000;
const rawBody = '{ "id": "evt_1", "amount": 100 }\n';

function sign({ rawBody, secret, timestamp }) {
  const v1 = hmacHex(secret, `${timestamp}.${rawBody}`);
  return `t=${timestamp},v1=${v1}`;
}

const validHeader = sign({ rawBody, secret, timestamp: now });

assert.deepEqual(
  verifyWebhook({ rawBody, header: validHeader, secret, nowSec: now }),
  { ok: true, reason: "accepted" }
);

const reSerialized = JSON.stringify(JSON.parse(rawBody));
assert.notEqual(reSerialized, rawBody);
assert.deepEqual(
  verifyWebhook({
    rawBody: reSerialized,
    header: validHeader,
    secret,
    nowSec: now,
  }),
  { ok: false, reason: "signature" }
);

On this machine those two strings are:

wire: { "id": "evt_1", "amount": 100 }\n
re-serialized: {"id":"evt_1","amount":100}

Same object. Different bytes. Different HMAC. The test fails on purpose, which is the point.

In production this means: capture the raw body before the JSON parser, verify, then parse.

What if someone rewrites the timestamp?

A captured request already has a valid v1. If you HMAC the body alone, an attacker can keep v1, set t to now, and walk past a freshness check.

Put t inside the signed payload. Then bumping the timestamp invalidates v1.

const bumped = `t=${now + 60},v1=${validHeader.split("v1=")[1]}`;
assert.deepEqual(
  verifyWebhook({ rawBody, header: bumped, secret, nowSec: now }),
  { ok: false, reason: "signature" }
);

const stale = sign({ rawBody, secret, timestamp: now - 301 });
assert.deepEqual(
  verifyWebhook({ rawBody, header: stale, secret, nowSec: now }),
  { ok: false, reason: "replay" }
);

301 seconds is one second past Stripe's default window. The signature is valid. The request is still rejected. That split is the sentence interviewers are listening for: authenticity and recency are two checks, in that order.

Secret rotation is the last fixture. Stripe can send two v1 values while both secrets are live. Accept if any candidate matches the secret you currently trust.

const rotated = sign({ rawBody, secret: "whsec_new", timestamp: now });
const dualHeader = `${validHeader},${rotated.replace(/^t=\d+,/, "")}`;
assert.deepEqual(
  verifyWebhook({
    rawBody,
    header: dualHeader,
    secret: "whsec_new",
    nowSec: now,
  }),
  { ok: true, reason: "accepted" }
);

Run the file with node verify.mjs. All five assertions should print nothing except your own log line.

What do you say when they ask about trade-offs?

Choice	What you gain	What you pay
Raw body, not `JSON.stringify`	Signature matches the provider	You must buffer the request before parsing
Timestamp inside the HMAC	Attackers cannot freshen a captured `t`	Clock skew becomes a production concern
300s tolerance	Official Stripe default, NTP-friendly	A 4-minute replay still lands
`timingSafeEqual`	No byte-by-byte oracle	You must guard buffer length
Multiple `v1` values	Zero-downtime secret rotation	A leaked old secret stays valid until you drop it

The honest limitation: this drill is process-local. It does not replace event-id dedupe. Providers retry. A valid request can arrive twice inside the five-minute window. Signature verification proves who sent it, not that you have never processed evt_1 before. Idempotency on the event id is a separate contract.

Also return 2xx fast. Stripe will retry if you do the slow work on the request thread. Verify, enqueue, respond. Parse and fan-out after.

How I rehearse the live explanation

Once the assertions pass, the remaining failure mode is talking. "Walk me through this file" is the actual round, and it is where people who pasted a Stack Overflow snippet get stuck.

I keep a short script:

Point at the raw-body buffer and say what would happen if Express parsed first.
Point at ${t}.${rawBody} and explain why t is not a separate header check.
Name the 301-second fixture and the 5-minute default from Stripe's webhook docs.
Admit what this does not prove: duplicate evt_1 inside the window.

I use aceround.app — AI interview assistant to run that walkthrough out loud, with interruptions, until the four steps come out in a stable order. The code is the evidence. The interview is whether you can defend it.

FAQ

Can I HMAC JSON.stringify(req.body) if I control both sides?
Only if you also control canonicalization. You usually do not. Providers sign the wire bytes. Hash those.

Is timingSafeEqual overkill for an HMAC?
HMAC already stops forgery. The compare still should not leak which prefix matched. Use it. Check lengths first so Node does not throw.

Why not set tolerance to 0?
Stripe's own docs say 0 disables the recency check. That is the opposite of strict.

Does this replace an official SDK?
No. Use stripe.webhooks.constructEvent in production. The drill exists so you can explain what the SDK is doing when the interviewer takes it away.

Drafted with AI assistance, then edited. Every assertion in this article was executed with Node.js before publishing.

Git Bisect Is an Interview Question: Find the Regression You Can Prove

Karuha — Thu, 27 Aug 2026 02:52:36 +0000

Liquid syntax error: 'raw' tag was never closed

Linktree Raised Prices Again — Here's What Freelancers Are Actually Switching To

Karuha — Wed, 26 Aug 2026 05:11:39 +0000

Linktree raised its prices again in late 2025 — Starter went from $5 to $8/month, Pro from $9 to $15. If you're a freelancer or indie creator paying for a "link in bio" page, that's a meaningful jump for something that's fundamentally a list of links.

I went looking for what freelancers are actually switching to, and it comes down to three real options depending on what you need.

If you just need links (no frills)

Linktree is still fine if you're on the free tier or don't mind the new pricing. It's the most recognized brand, so if your audience already expects the linktr.ee look, switching has a cost too (broken muscle memory, re-sharing links everywhere).

Beacons is the closest like-for-like alternative — same link-list format, competitive pricing, decent free tier. Good if all you want is a drop-in replacement.

If you want something that reads as a real page, not a link list

This is where it gets more interesting. A plain link list looks fine on Instagram but falls apart the moment someone clicks through expecting a portfolio, case studies, or a way to actually contact you.

Tools built for this niche typically bundle:

A proper one-page layout (not just stacked buttons) with templates
A digital business card (vCard) so people can save your contact info in one tap — genuinely underrated for in-person networking, conferences, client meetings
Short links / QR codes for the same profile, useful for print materials or presentations
Basic visit analytics so you know if anyone's actually looking

I've been building one of these (Nameplate) — free for one page, $5/month if you need more, roughly the pre-hike Linktree pricing. Disclosure since I'm biased: it's mine. I'm not going to pretend it's the only option, but it's representative of this second category (Carrd is the other well-known one here, more design-flexible but with a steeper learning curve for non-designers).

What actually matters when picking one

Custom domain support — if you're serious about a personal brand, a yourname.com you control beats a linktr.ee/yourname URL you're renting.
Whether the free tier is usable long-term, not just a trial. A lot of "free" tiers here are 14-day trials in disguise.
Export / portability — can you get your data out if the company pivots or shuts down? Worth checking before you invest hours customizing anything.
Actual page load speed — some of these tools ship a lot of JS for what's essentially a static page. Worth a quick Lighthouse check before committing.

If you're just annoyed about the price increase and want a quick swap, Beacons is the least-friction move. If you've been wanting an excuse to build something that actually represents your work instead of a stack of buttons, this is a good time to look at the portfolio-style options.

DEV Community: Karuha

NFC vs QR: which business card actually gets scanned

What's actually being transmitted

Where NFC actually breaks

Where QR actually breaks

Cost, and who controls the card afterward

A two-minute test if you already have both

What neither format fixes

HackerRank AI-Assisted Interview: If the Assistant Won't Write Code, Check the Question Type

What actually gets turned on?

Why does Guarded mode look broken?

What does the interviewer actually see?

What does a strong Code Repo session look like?

How is this different from a HackerRank OA?

A 20-minute practice you can run tonight

The Second Worker Never Saw Job 2

What does FOR UPDATE LIMIT 1 actually wait on?

Why is job 2 still queued while worker 2 is idle?

Can you prove the wait without standing up Postgres?

Why does OFFSET lock rows you never returned?

How do you say this in the interview?

Forgot client.release()? Postgres Never Sees Request 11

What does the interviewer actually mean by "the pool is exhausted"?

Why does pool.connect() hang instead of throwing?

How do you prove the checkout contract without standing up Postgres?

What do you say when they ask how big max should be?

How do you narrate this in a backend / SRE interview?

What I would not say

Drain In-Flight HTTP Before Kubernetes Sends SIGKILL

What is the interviewer actually asking?

Why doesn't server.close() by itself finish the job?

How small is the pad version?

Which four contracts do you have to show?

What do you say out loud in the backend / SRE round?

FAQ

Fencing Tokens Stop the Write Your Redis Lease Already Released

What is the interviewer actually asking?

Why doesn't checking the lease just before the write save you?

How small is the pad version?

Which six contracts do you have to show?

What do you say out loud in the system-design round?

FAQ

Why JWT Refresh Token Rotation Fails Without a Token Family

What do interviewers actually want when they say "rotate the refresh token"?

Why does deleting the old token fail the theft case?

Which five contracts do you have to show?

What do you say out loud in the 45-minute backend round?

What this is not

FAQ

Google's AI-Assisted Coding Interview: Catch the Cached 503 the Model Will Ship

What does Google's AI-assisted coding interview actually score?

Why does caching the in-flight promise look correct?

How do you prove the 503 is still sticky?

What should you say out loud while Gemini is typing?

What this format is not

FAQ

Transactional Outbox in Node.js: Never Publish Outside the Transaction

What is the interviewer actually asking?

How does a dual-write fail in code?

How do you commit the event with the order?

How does the relay claim rows without blocking?

Why is the consumer still responsible for duplicates?

How do you narrate this in the room?

FAQ

Webhook Signature Verification in Node.js: Hash the Raw Bytes

What is the interviewer actually asking?

How do you build the signed payload?

Why does JSON.parse break a valid signature?

What if someone rewrites the timestamp?

What do you say when they ask about trade-offs?

How I rehearse the live explanation

FAQ

Git Bisect Is an Interview Question: Find the Regression You Can Prove

Linktree Raised Prices Again — Here's What Freelancers Are Actually Switching To

If you just need links (no frills)

If you want something that reads as a real page, not a link list

What actually matters when picking one

What does `FOR UPDATE LIMIT 1` actually wait on?

Why does `OFFSET` lock rows you never returned?

Why does `pool.connect()` hang instead of throwing?

What do you say when they ask how big `max` should be?

Why doesn't `server.close()` by itself finish the job?