Court booking at the opening second — operating principles

A description of a system that reliably takes four courts the moment a 21-day booking window opens. No file paths, no code, no product names: only the mechanism and what is actually proven.

The setting

Slots open exactly 21 days ahead, on the hour. Everything is decided in the first seconds. Courts released later are of no interest.

1. Preparation ends before the window opens

Preparation starts four minutes before the hour. In that window the application opens a separate authenticated session per account, verifies identity and reads credit. Four accounts are prepared; two are designated as buyers for that hour.

Everything that can be checked is checked here, because nothing is checked afterwards.

2. The clock starts preparation; the server grants permission

The clock never authorizes a purchase. The application repeatedly reads the authenticated reservation page for the exact target date and hour and classifies the answer as OPEN, CLOSED or UNKNOWN.

An HTTP 200 is necessary but not sufficient. OPEN requires the server-rendered reservation data to offer that exact slot, with matching identifiers, times and reservation boundaries.

Anything ambiguous, missing or conflicting is UNKNOWN. Uncertainty never becomes permission to buy, not even in the final seconds. If the deadline passes without a proven OPEN, no purchase starts.

OPEN means the window offers the slot. It does not mean a given court is still free — only the order and confirmation responses settle that.

3. Everything that can be built in advance is built in advance

Payloads for all three transaction steps are serialized before opening. After OPEN only the returned order ID is inserted into the subsequent requests. This takes work out of the critical path without giving anything up.

4. The transaction sequence stays minimal

Per account, strictly sequential:

create order → select credit payment → check → confirm → verify payment and tickets

Reads of price, credit and reservation state sit outside this sequence. Nothing is verified between the steps.

5. Accounts buy concurrently, with non-overlapping assignments

Both buying accounts start at once on separate authenticated sessions, each taking two courts. Neither waits for the other. Reserve accounts exist for courts left unresolved and are processed sequentially, only after both primary outcomes are known.

Four courts on one account is permitted by the venue; splitting across two accounts is simply faster.

6. Do not recreate the venue's business rules as local blockers

Let the booking server decide capacity, eligibility and payment acceptance. Local vetoes on credit versus estimated price, fixed daily limits and a hardcoded booking horizon were removed as redundant — they can act on stale data and refuse an otherwise valid purchase.

Lateness in preparation or reaction is recorded as a diagnostic, never as a reason to abandon an otherwise permitted purchase. A failure in optional reporting must not stop a transaction.

What stays on our side: the authorized account, date, hour and courts; a proven OPEN; respect for STOP; and verification of the real outcome.

7. Success is established from evidence, not from a status code

After the pipelines finish, the application checks active paid reservations, ownership, tickets and credit. An HTTP success is not payment proof.

Measured

The 12–33 ms is the application's reaction after receiving OPEN, not the purchase duration. The rest is network and server time.

Proven, and not proven

Proven. Four courts taken for both hours on the live opening. Concurrency resolved by the server: in a separate live test two machines bought the same courts; one received paid tickets, the other received 409 CapacityCheckFailed at confirmation.

Not proven. That the open-proof is re-verified before each write — it is fetched once and reused for the whole sequence. That filesystem-based locks protect anything across machines — they do not; the server does. That any later release is measurably faster in a controlled live comparison. That immediate retry after a transport timeout is harmless for every uncertain transaction outcome.

The distinction between what is proven and what is intended is kept deliberately.

Written at the fence. Nothing here identifies the venue, the code or the machines — only the mechanism.