TravelBusinessFirst
A premium business-travel booking platform built in Next.js and Node.js with Redis caching and Stripe payments. The engineering problem was normalising fare data from multiple suppliers into consistent, accurate pricing at a search latency business travellers would tolerate.
The problem
Fare data is messier than it looks from outside. Different suppliers return different structures, different fare bases, different rules about what is included, and different opinions about availability — sometimes for the same seat. Normalising that into something a traveller can compare is most of the work, and it has to happen fast enough that nobody abandons the search.
The second problem is harder and less visible: staying honest. A fare that looks right in search and changes at checkout is the single fastest way to lose a business traveller, and caching aggressively enough to be fast makes it more likely, not less.
What we built
- A fare normalisation layer translating supplier responses into one comparable shape.
- A caching strategy tuned to keep search fast without letting quoted prices drift from what is actually bookable.
- A search experience built for a traveller who knows what they want, rather than one browsing inspiration.
- Stripe payments wired into a checkout that has to agree with the price shown at search.
Why this stack
| Layer | Choice | Reasoning |
|---|---|---|
| Front end | Next.js | Server rendering keeps landing pages indexable while the search itself stays interactive |
| Backend | Node.js | Supplier calls are I/O-bound and heavily concurrent, which suits the model well |
| Caching | Redis | Sub-second reads on normalised fare data, with explicit control over how long a price is trusted |
| Payments | Stripe | Mature handling of the awkward parts — 3-D Secure, refunds, reconciliation |
The trade-off worth naming
Every fare search platform makes the same bargain: cache longer and it is faster but more likely to be stale; cache shorter and it is accurate but slow enough to lose people. There is no setting that wins both. The useful work is deciding which data can be cached hard, which must be revalidated before checkout, and where to re-check so the user sees a correction early rather than at payment.
If you are building something with supplier integrations and latency requirements of this kind, tell us about it — the architecture decisions above are the ones worth getting right early.