Smart Reservation Platform

The business problem

Naive booking code checks availability and then writes a reservation, which leaves a window where two requests both see the slot as free. Payment makes it worse: gateways retry their callbacks, so the same successful payment can arrive two or three times, and any handler that is not idempotent will create duplicate reservations or duplicate credit against a single payment.

What I delivered

• A buyer deposit and reservation foundation where the reservation is created against a confirmed payment rather than optimistically.
• Idempotency on the WooCommerce payment callback, so a repeated notification for the same payment produces the same single reservation.
• Admin-defined capacity and time rules, so the constraints are configuration rather than being encoded in the booking logic.
• A status history and timeline on the underlying record, so the sequence of states a reservation passed through is readable afterwards.
• An audit and events layer beneath it, so state changes are recorded as they happen rather than reconstructed from the current row.
• Feature flags and a schema manager, so the reservation work could be developed and enabled independently of the rest of the platform.

Technical approach

• Idempotency is designed in at the callback, not added after the first duplicate. Gateway retries are normal behaviour, not an error condition, and a handler that assumes exactly-once delivery is wrong from the first day.
• Capacity and time rules are admin-defined so that the same architecture serves different business models without a code change, which was the point of building it as a reusable foundation.
• State transitions are recorded as history rather than overwritten, because a reservation dispute is always a question about the sequence, not the current state.
• The work sits behind feature flags with its own schema management, which is what allowed it to ship incrementally into a live platform.

Result and evidence

Reservations are created once per confirmed payment regardless of how many times the gateway calls back, and the capacity rules are configuration rather than code. The foundation is in place through the reservation and deposit stage; certificate issuance, delivery and settlement are separate later stages.

Commercial value

Double-booking and double-charging are the two failures a reservation system cannot have, because both are visible to the customer and expensive to unwind. Designing for them first is much cheaper than detecting them later.