Skip to content

Notes/real time · MongoDB · reliability

One bid, exactly once — idempotency inside the write that claims the price

In a live auction the question isn't "did the request succeed?" but "what do we answer the one that comes back?". A design decision from Maison Dlala.

2026-11-12 · 2 min · Mohamed Abi

A buyer confirms a bid of 5,500. The request goes out, the server accepts it, then the network drops before the reply. The browser can't tell whether the bid landed. It retries — perhaps on another API instance.

What should it get back?

What already protected us, and what was missing

On Maison Dlala, a bid was already accepted by one atomic conditional update on the sale: the offered price must beat the best price, the sale must be open, and the clock is the server's. A unique index prevented storing the same bid twice. "Executed twice" was therefore already impossible.

But the retry got a refusal — amount too low, since the price had just risen… because of it. The client was told "refused" for a bid that had landed. And without multi-document transactions, a crash between claiming the price and saving the bid could leave a raised price with no matching bid.

Put the key in the same write

Every bid confirmation generates a key in the browser. The temptation is to record it afterwards, in a deduplication table. That protects nothing: the window between the two writes is exactly where things break.

So the key is recorded inside the same atomic update as the price. The update's condition checks both that the price is better and that the key was never seen for this bidder; the write sets the new price and the key together. A key can claim only once, on any instance, because the database decides.

Answering the request that comes back

When a bid is refused, the server first checks whether its key already claimed the price:

  • same key, same amount: it returns the original receipt — no second bid, no false refusal;
  • same key, different amount: 409, key reuse refused, even under concurrency;
  • key claimed but bid missing (the crash): the situation is settled on this attempt.

Old clients without a key follow the old path, unchanged.

What I keep from it

The guarantee must live in the operation that decides, not around it. Redis carries events between instances, but it decides nothing: if Redis goes down, no bid is lost or duplicated, because the truth is in a single MongoDB write.

Maison Dlala's repository is private; this note describes the principle, not the code.

The full case studyMaison Dlala: live auctions where the server is always right →