Skip to content

How would you show live seat counts without overselling?

1 min read · main part only; folded sections are optional

After this you can answer: How would you show live seat counts without overselling?

First ask whether the interface needs a fast estimate or numbered-seat selection. This app sells quantities from an event’s remaining capacity, not individually reserved seat positions. A live number must not imply that the displayed quantity is reserved for the viewer.

A proposed event would contain event ID, committed inventory version and count. Publish after the transaction commits, ideally through durable intent rather than an unprotected post-commit network call. Consumers discard older versions and fetch a fresh snapshot when they detect a gap or reconnect.

A single API process cannot broadcast to clients attached to every replica without a shared distribution path. Define reconnect limits, per-event fan-out, authorization and slow-client behavior before choosing transport. Existing booking invalidation and cached event lists are not a push protocol. The current locked transaction remains the correctness boundary even if a client sees a stale count and receives a sold-out conflict.

Could Redis become the authoritative seat counter?
That changes the consistency and recovery design. The current gate is advisory; Postgres still checks and updates capacity under a row lock.
Why might polling be preferable?
It is simpler to operate and naturally recovers from disconnected clients. Its cost is repeated reads and bounded staleness.
What happens when the stream fails?
Show stale-state feedback or fall back to snapshots. Booking must still validate inventory; display transport failure must not create seats.

Read the path chapter, select the relevant map piece →, then inspect apps/api/src/queries/bookings.ts → createBookingTx.

Read this book online: https://book.theversehub.in/