This week I shipped reserved seating into eventOS.
The visible interaction is familiar. A buyer opens an event, chooses where they want to sit and continues toward checkout.
The engineering problem underneath it is more interesting because a seat is scarce inventory. Two people can want the same one, a buyer can abandon checkout after making a selection, and the interface can become stale while somebody else is acting on the same event.
That changes the problem from drawing a seat map to deciding what the system is allowed to promise.
Selection is not ownership
Clicking a seat is an expression of intent. It should not be treated as permanent ownership simply because the browser changed colour.
The platform needs a temporary reservation boundary while checkout is in progress. That reservation has to expire cleanly if the purchase does not complete, and the system has to remain authoritative when two clients disagree about what is still available.
The principle I kept coming back to was simple: the interface can express preference, but the product has to decide what can actually be reserved.
Temporary state still needs rules
Temporary state is easy to underestimate because it is supposed to disappear.
A hold still needs a beginning, an end and a clear outcome. If the buyer completes the purchase, the reservation becomes part of the durable ticket context. If they walk away, the inventory needs to become available again without requiring somebody to repair it manually.
That is the part of reserved seating that interested me most. The hard question was not how to render rows and seats. It was how to make a short-lived promise behave predictably under real user behaviour.
Best available is an allocation decision
"Best available" looks like a convenience button, but it is still a decision under constraints.
The system has to choose from what is genuinely available while respecting the event's seating configuration and the buyer's request. That makes it closer to an allocation problem than a shortcut around the seat map.
Again, the useful boundary is between preference and authority. A client can ask for a quantity or a location preference. The final assignment has to come from the same source of truth as availability.
The assignment has to remain meaningful after checkout
Reserved seating would be fragile if the assignment mattered only on the purchase screen.
Once a ticket exists, its seating context needs to remain understandable anywhere the product later needs to present or operate that ticket. I do not want each surface inventing its own interpretation of where somebody is meant to be.
That is a broader product-engineering lesson I keep encountering: state becomes valuable when it survives the screen that created it.
What I would show publicly
The useful public proof for this work is the attendee experience, not the private control plane behind it.
A portfolio capture should show the seat-selection experience, the difference between available and temporarily unavailable inventory, and the resulting seat context after purchase. It does not need to expose internal routes, timing rules, staff controls, database structure or operational tooling to prove the engineering work exists.
That is the standard I want for eventOS in the portfolio: show enough of the product to make the work tangible, explain the engineering decision that made it reliable, and keep the implementation-sensitive parts of a live commercial platform private.