Urmi: from availability to confirmed booking
A code walkthrough of appointment persistence and the notification flow for a salon website.
View source code ↗Problem
The site lets customers choose a service and appointment slot, then routes booking information to the salon.
Constraints
The implementation must coordinate an available slot, a persisted booking, and notifications across several external services. This is a constraint visible in the code, not a documented original product brief.
Architecture
The availability route reads non-cancelled slots for a date. The booking route checks for an existing slot, inserts a confirmed booking, then sends notifications. An admin route lists bookings and updates their status.
Technical tradeoff
The booking route keeps persistence and notification orchestration together. This makes the sequence easy to follow, but external notification work is coupled to the request. That tradeoff is inferred from the implementation; the original decision rationale has not been recorded.
Failure modes & verification
A failure mode to test is two simultaneous requests for the same slot: the route checks availability before inserting. A database constraint or transaction would need to enforce exclusivity independently of that check. This is a review finding, not a claim that a production incident occurred.
Next iteration
Proposed next iteration: enforce booking exclusivity in the database, check insert errors before sending confirmations, and make notification delivery independently retryable.
Evidence & metrics
No verified booking volume, latency, or uptime measurements are available for publication. The linked routes provide inspectable implementation evidence.