Why Don't Two People Book the Same Seat on a Flight?

A seat can be in several states

Two fingers move toward 12A

Person A taps the seat in Johannesburg. Person B taps the same seat somewhere else almost simultaneously.

Both screens were showing information that was true a moment earlier. The database now has to settle the race.

How the seat becomes yours

Concurrency: many actions happening together

Concurrency is what developers call situations where several users or processes act on shared data at nearly the same time.

The system can use database transactions, locking or carefully designed conditional updates so only one request changes the seat from available to held.

Everyone else receives the new truth: the seat is no longer available.

The payment succeeds, but the confirmation screen fails

This is one of the uncomfortable edge cases booking systems must plan for.

The system needs a transaction reference and a reliable booking state so it can determine whether payment succeeded, whether the seat was confirmed and whether a retry would accidentally charge again.

A customer should not have to guess whether they own the seat.

What if the new aircraft has a different seat layout?

An airline may replace the planned aircraft. Row numbers, cabin sections or available seats can change.

Software then has to map passengers to the new layout, preserve preferences where possible and clearly communicate changes.

The seat is part of a living operational system, not only a picture on a booking page.

The same seat may appear on several sales channels

Customers can book through an airline website, mobile app, travel agent or partner system. These channels must ultimately agree about the same inventory.

If each channel kept an isolated copy for too long, one seat could appear available in several places after it had already been sold.

A place on the aircraft and a particular seat are not always the same thing

A ticket or confirmed reservation can represent the right to travel on a flight, while seat assignment identifies a particular place in the cabin. Airlines may manage these as connected but separate records because aircraft changes, accessibility needs and operational decisions can alter the seat map.

This explains why a traveller can have a confirmed booking before choosing a seat, or why a previously selected seat can later change even though the flight reservation remains valid.

What if the customer presses Pay twice?

A slow response can make a customer think nothing happened. Pressing again may send a second request. Reliable systems use unique booking and payment references so a retry can be recognised instead of automatically creating another charge or another reservation.

Developers call this idea idempotency: repeating the same identified request should not repeat the business result. The word is technical, but the purpose is simple, one intended purchase should create one booking.

A seat can disappear and later return

A temporary hold may expire, a traveller may cancel or a failed payment may release the seat. Conversely, an airline may block seats for crew, weight distribution, families, accessibility or an aircraft change.

The seat map is therefore a live view of current rules and records, not a permanent photograph. Refreshing can reveal a new state because something real changed after the earlier view was loaded.

Explore more stories about aviation, payments and software in all published articles.

The database transaction

A transaction groups important changes into one controlled operation. Either the valid changes complete together, or the system can roll them back.

This protects the relationship between the passenger, booking, payment and seat.

People are not booking database rows

They may be choosing a window for a child's first flight, an aisle for comfort or nearby seats for a family.

That is why a small square labelled 12A can carry real importance. Software protects the promise made when the confirmation arrives.

Receive a seat confirmation