Engineering · System integrity
Reserve
One resource. One valid commitment.
01
In plain English
- What it is
- A booking tool designed to keep two projects from being promised the same room, equipment or resource at the same time.
- How it works
- You would choose a slot, including any setup time. Reserve would hold it briefly while you confirm. If someone else secures it first, you would be asked to choose another slot.
- Why it matters
- To prevent conflicting commitments and make a confirmed booking mean something the team can rely on.
02
The working model
Availability can change between looking and booking. The write decides which commitment is valid.
The boundary that matters This simulation illustrates a proposed database rule; it does not test concurrent production bookings.
Two paths: Standard flow and Competing booking · 5 stages each
03
How it fits together
A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.
Read the diagram source
%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
accTitle: How Project Reserve works
accDescr: A project manager selects a resource and time. Signal checks live availability and places a temporary hold only if no other valid booking overlaps. Confirmation checks that the hold remains valid before recording the booking. A taken slot or expired hold prompts another choice. The proposed reservation rules must be enforced by the booking system, not only the screen.
A(["Project manager<br/>Chooses resource and time"])
B("Booking system<br/>Checks overlapping reservations")
C("Temporary hold<br/>Keeps the slot briefly")
D{"Hold still valid<br/>when confirmed?"}
E("Confirmed booking<br/>One valid commitment")
X("Slot unavailable<br/>Choose another time")
A --> B
B -->|Available| C
C -->|Confirm booking| D
D -->|Valid| E
B -->|Already taken| X
D -->|Hold expired| X
classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
class A human;
class B,C work;
class D decision;
class E result;
class X exception;
04
The case study
Availability is a helpful read; a reservation is an invariant the database must enforce.
The problem
Two users can see the same free slot and click reserve almost simultaneously. Checking availability in the interface cannot ensure that only one overlapping booking succeeds.
The insight
Enforce non-overlap at the write boundary, where competing reservations are decided atomically.
The system
The proposed model uses time ranges, explicit buffers, and a database non-overlap constraint for blocking reservations. Temporary holds have a defined expiry lifecycle. Confirmation, cancellation, and retries operate atomically with a stable request identity.
The rationale
A clear rejection at booking time is preferable to discovering that two projects were promised the same physical resource.
Responsibilities
- Availability view
- Helpful current state, not a promise of ownership.
- Atomic reservation
- Enforce non-overlapping ranges and buffer rules.
- Reservation lifecycle
- Explicit holds, expiry, confirmation, and cancellation.
The boundary
The database controls reservation validity. Cached availability and client-side checks are advisory views of that state.
The trade-off
A strict invariant can reject a booking after a user saw availability. The interface must explain the conflict and help them choose another slot.
When it fails
Two requests arrive together
Commit at most one overlapping reservation and return a meaningful conflict for the other.
A hold expires during confirmation
Check expiry within the confirmation transaction and require a new reservation if the hold is no longer valid.
Cancellation is retried
Return the existing cancelled outcome without releasing or altering a different reservation.
Evidence Design proposal · local demonstration uses synthetic data
05
On the design side
Holding a resource is the same shape as holding a seat, which the seating deck works through in detail.
Seating
Building the room, placing people and encoding the rules.