# Make two requests compete for the last place

A deterministic race test proves the capacity rule more clearly than a large burst of requests that may never overlap at the critical point.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Create a small known state

Set up a synthetic session with capacity one and no confirmed bookings. Use two distinct request identities so duplicate handling does not accidentally collapse the test into one operation.

Run both requests through the real reservation path. Arrange a barrier at the point needed to expose the old read-then-write race, or use database coordination appropriate to the implementation.

Avoid relying on arbitrary sleeps. The test should know that both requests reached the intended state before continuing.

## Release the competing work

Allow both operations to proceed and collect their responses. The expected result is one confirmed booking and one defined failure or alternative outcome, according to the product's policy.

Inspect the database independently. A response can report failure after a booking was committed, so counting successful HTTP responses alone is insufficient.

Check related state such as remaining capacity, reservation records and outgoing confirmation intents. They must agree with the single accepted booking.

## Add interruption at the commit boundary

Repeat with one request losing its connection after commit but before receiving the result. Retry that same operation identity and confirm that it does not consume another place.

Then test a different request competing while the first transaction is delayed. This separates duplicate recovery from contention over the business resource.

If the implementation retries aborted transactions, verify that the whole protected decision is recomputed. Reusing an availability value from the first attempt defeats the reason for retrying.

## Exercise release and cancellation too

A booking system usually returns capacity when a reservation is cancelled or expires. Race confirmation against expiry and cancellation against retry. State transitions need to prevent one reservation from releasing capacity twice.

Use a small state table in the test documentation showing which transitions are valid. The final invariant should hold across the lifecycle, not just initial creation.

Keep assertions about actual business state and operation results. Timing and throughput measurements can supplement the test, but they cannot establish that the last place was allocated correctly.

## Sources

- [PostgreSQL: transaction isolation](https://www.postgresql.org/docs/17/transaction-iso.html)