The release goes live: code reviewed, checks passed, everything you tested worked as expected.
Then a customer reports two charges for one purchase. A slow payment service leaves other screens waiting. A logged-in customer changes a booking reference and accesses someone else’s details. And a new feature turns out to skip a check the old one always ran.
You don’t need to work in airlines to recognise these surprises. They show up across domains such as retail, e-commerce, and banking, financial services and insurance (BFSI)—from a shopping checkout to a money transfer or a regular online payment. These are real-life issues for end users.
Why these can surface after release
A feature can work in a quiet demo yet fail when replies slow down or requests overlap.
Imagine a busy sale with hundreds of customers paying at once. Payment replies slow down, but new requests keep arriving. Waiting payments pile up and can tie up the workers that also handle searches—so even customers just browsing can get stuck.
Problems 3 and 4 can happen even with just one user: a customer can access someone else’s booking, or the booking feature can skip a payment check. Neither requires heavy traffic.
Are you in the same boat?
At CodeWalnut, our work on an airline system helped shape the backend practices we follow. Here are four problems and how we address them, using simplified examples—not specific client incidents. The practices apply across languages and frameworks.
Let’s dive into the problems.
1. Booked once. Charged twice?
Ravi pays for his booking. The payment succeeds, but the confirmation never reaches him. The screen offers “Try again”, so he taps it. The backend treats that as a new purchase and charges the same booking a second time.
A missing reply does not mean a missing payment.
2. Slow payments. Search stuck?
The payment provider is slow. Flight search does not call it, yet searches start waiting too. Why? Both use the same pool of workers. Workers waiting for payment replies cannot pick up a search.
3. Your login. Someone else’s data?
Meera opens her booking, B100. Then she changes the request to B200, Ravi’s booking, and receives his details. The backend checked who she was, but not what she was allowed to read.
That does not take an attacker. The reference sits in the URL bar, in the confirmation email and in every support ticket. Someone curious tries the next one, and the backend answers.
Being signed in does not make every booking yours to read.
4. Booking added. Payment check skipped?
Seat selection already checks payment before saving a reservation. Then you add booking, which saves reservations directly through the database code. The new feature never runs the existing payment check.
How does that reach production? The failed-payment case was written once, against seat selection. When booking arrived it was tested the way new features usually are — a successful payment, a saved reservation, the expected result. Nobody ran an unsuccessful payment against the new path. The test exists. It was never pointed at the second entry point.
Pick one flow. Ask four questions.
Can it run twice safely? Can it get stuck waiting? Can the wrong person access it? Can another path skip its rules?
Start there—not with a rewrite.
Next: the confirmation screen shows a flight and seat. What else did the backend send to the browser? We’ll look at internal data that accidentally becomes public, and how to keep it out of a response.
When to Hire CodeWalnut?
