Timed Auction Service · Analysis

01 · Frame the problem

Understand the central challenge

Model a fictional single-currency auction using exact integer units. Use a fixed closing deadline, no automatic extensions, one highest eligible bid and no payment settlement in this exercise.

The authoritative auction clock and serialized bid state determine deadline eligibility. Display order, client timestamps and delayed notifications cannot safely decide the winner.

02 · Find the design pressure

Start simple, then identify the gap

Begin with one serialized bid authority and explicit increment rules. A timer that closes an independently writable bid table leaves a boundary race. Validate deadline and append under the same lock, then persist one final outcome.

Give each auction one serialized write authority. Check its deadline and increment policy under the same lock as bid insertion, then finalize exactly one outcome with an outbox event independently of projection or notification delays. Define fixed end time, exact unit bounds, increment, bidder eligibility and the admission-time ordering contract. Route writes to one fenced authority per auction. Scope idempotency by bidder and auction and compare immutable payloads. Check an existing result first; then lock the auction, read authority time and reject after the deadline or when the required increment is not met. Append the accepted bid and update the highest bid atomically. Return the committed sequence so the caller can distinguish acceptance from a delayed read projection. The close worker locks the auction after the deadline, snapshots the committed highest eligible bid and stores CLOSED plus a winner/no-bids event in one transaction. Retries return the same outcome; payment execution is a separate workflow.

03 · Define success

Requirements to preserve

Validate and serialize bids at an authoritative service.
Bind bid idempotency keys to immutable request contents.
Enforce deadline during bid admission, not only in a close worker.
Publish a stable winner and closing event atomically.

Workload: 30,000 reads/s, 7,000 writes/s, 500 B records, 120 ms read p99 target. These are exercise assumptions; the Solution includes capacity formulas.

04 · Identify the correctness boundary

Consistency, ownership and failure boundaries

Check bid deadlines under the same serialization boundary that records bids. Client timestamps and delayed read projections cannot decide acceptance. Closing creates one immutable outcome and dispatch intent, while payment or notification remain separate tracked workflows rather than reasons to reopen bidding.

05 · Make it concrete

Reason through a worked example

A bid enters the server before the deadline but reaches the authoritative lock afterward. Its acceptance follows the defined authority-time rule, not its client timestamp. Two close workers racing produce one final outcome. A delayed display update cannot change the committed winner.