Capacity is a state, not a number.
What ticket availability taught me about modelling real-world inventory.
An event can have a capacity of 300 and still not have 300 tickets available. The useful number is the result of a system: what has sold, what is temporarily reserved, what can be released and what the current ticket rules allow.
The checkout changes inventory before payment succeeds.
A buyer needs time to complete payment. If the system waits until payment succeeds before accounting for that ticket, two people can be offered the same final unit. If the reservation lasts forever, abandoned checkouts quietly remove inventory from sale.
Efecto Placebo therefore treats temporary reservation as a real inventory state rather than an implementation detail.
Availability is derived.
The sellable quantity is calculated against controlled capacity while accounting for paid tickets and active reservations. Failed or abandoned payment paths release the reservation so the inventory can become available again.
That creates a simple lifecycle — available, reserved, payment, paid, ticket issued — with an explicit route back to availability when payment does not complete.
State models are product design.
This is not only backend correctness. The state model determines what a customer can buy, what operations teams can trust and whether the door receives a valid ticket later. A product can look finished while its state transitions are still vague.
I now treat the lifecycle diagram as part of the interface work. If the states cannot be explained clearly, the product probably does not understand them clearly either.