Reservation System

Start by clarifying what is reserved: a numbered seat, a hotel room type, an appointment slot, or a quantity of interchangeable inventory. Ask whether temporary holds are needed, how long they live, whether overbooking is allowed, and whether a successful payment must imply a confirmed booking immediately. Model reservations with an immutable identifier, resource or inventory key, time range, status such as held, confirmed, cancelled, or expired, an expiry timestamp, and an idempotency key.

The critical operation is an atomic claim of availability. For a single seat, use a unique constraint on (resourceId, timeslot) or an optimistic conditional update. For fungible inventory, atomically decrement only when remaining capacity is positive, then create the hold in the same transaction or compensating workflow. Expire holds with a scheduled cleanup and release capacity exactly once. Index availability queries by resource and time; make payment callbacks idempotent because retries and races are normal. Test concurrent claims, duplicated requests, payment success after hold expiry, cancellation, and clock skew. Read availability is often O(log n + r) with indexes, while the correctness-critical claim must be atomic rather than merely fast.