Skip to content

CONCEPT Cited by 1 source

Stale-quote rejection

Definition

A client-request design in which the client-observed state (typically a price, option, or version value) is submitted back to the server as part of the write request, and the server rejects the write at the database level if that observation is no longer valid at write time. A slippage tolerance can be supplied alongside to define the acceptable delta between observation and write-time state.

Canonical wiki statement

From the 2026-02-19 PlanetScale × Cloudflare Hyperdrive demo (prediction-market app; Source: sources/2026-04-21-planetscale-faster-planetscale-postgres-connections-with-cloudflare-hyperdrive):

"Our application simply wouldn't work if the latest data wasn't always rendered. The logic of our application should ensure at the database level that option purchases won't proceed if the purchase price as seen by the user is not a valid price at the time the transaction is written to the database."

And on how the client request carries the validation data:

"Each request carries expected price/version data and slippage tolerance, so the backend can reject stale quotes while successful writes immediately broadcast over WebSockets to every connected browser."

Why it's needed

The hazard comes from the authoritative-vs- fast-notification split: clients see a WebSocket-pushed price before they see the next DB read, so their action (e.g. buying an option at $0.42) may race against a concurrent transaction that has moved the price to $0.45. Three failure modes if stale-quote rejection is absent:

  • Client buys at a price the market no longer offers — silent violation of the displayed contract.
  • Heavy traders arbitrage the WebSocket latency window systematically.
  • Application displays one price, DB persists a transaction computed against another — UX inconsistency and potential financial loss.

The solution is to re-authenticate the observation at commit time: the client's view of the price is part of the write predicate, and the DB refuses to commit if the view is no longer current.

Request shape

The canonical request carries three fields beyond the intent:

  1. Expected value (e.g. option price at UI time).
  2. Version / cursor (optional — version of the row / market / epoch the client observed).
  3. Slippage tolerance (acceptable delta between observation and write-time value; e.g. "accept if within ±2c").

Server logic:

-- pseudo-SQL
UPDATE option_positions
SET shares = shares + :purchase_shares, ...
WHERE market_id = :mid
  AND current_price BETWEEN :client_price - :slippage
                        AND :client_price + :slippage
  AND version = :client_version;
-- if affected rows = 0, reject with STALE_QUOTE

The row-level WHERE clause does the validation atomically with the write — no separate SELECT-then-UPDATE race window.

Why DB-level (not app-level)

The PlanetScale post is explicit: "the logic of our application should ensure at the database level that option purchases won't proceed if the purchase price as seen by the user is not a valid price at the time the transaction is written to the database."

Validating at the database level rather than in the application layer avoids a check-then-act race (concepts/check-then-act-race): if the application reads the current price, compares, then issues the write as a separate statement, another transaction can slip in between the check and the act. An atomic UPDATE ... WHERE current_price = ... is one statement, one row lock, and therefore race-free against concurrent writes.

Adjacencies

  • Similar in shape to optimistic-concurrency-control (OCC) with a version column — the expected value plays the role of the OCC version.
  • Similar to concepts/idempotency-token but orthogonal — an idempotency token prevents the same write from being applied twice; stale-quote rejection prevents a different write from being applied under a false premise.
  • Generalises beyond prediction markets: any real-time UI with a volatile server-side value (inventory counts, ticket availability, live-auction bids, ride-hail surge pricing) can use the same shape.
  • The slippage-tolerance degree of freedom is unique to this shape — clients explicitly opt into a correctness / latency trade-off.

Seen in

Last updated · 347 distilled / 1,201 read