Combined travel-package flow
- for
- Expedia (anonymous partner), via Globant
- when
- 2022–23
- Problem
- An anonymous partner had component endpoints but no combined travel-package flow.
- My contribution
- Designed and built the frontend and the BFF aggregation for a combined package flow.
- Result
- Combined travel-package flow in production for an anonymous partner.
- Status
- production · 2022–23
what I foundThe component endpoints already existed, so the missing pieces were the aggregation and the flow on top of them.
- Travel required unavailable
- Accommodation required unavailable
- Car rental optional unavailable
- Activity optional unavailable
No substitute is available.
Purchase is blocked and the team is alerted.
A partner substitute (partner-suggested equivalent) is tried automatically, then offered for you to replace.
Payment stays blocked until you accept the substitute.
It is left out of the package.
Payment goes ahead for the rest.
A partner substitute (partner-suggested alternative) is tried automatically, then offered for you to replace.
If you decline, it is left out and payment goes ahead.
Payment is blocked until availability is confirmed.
try it
When a component goes missing
Pick a situation
reconstruction, illustrative-
A required component is unavailable and the partner has a substitute.
→ The substitute is tried automatically, then offered for you to replace. Payment waits.
purchase blocked for now -
An optional component is unavailable.
→ It is left out of the package and the purchase continues.
purchase can continue -
A required component is unavailable and there is no substitute.
→ Purchase is blocked and the team is alerted.
purchase blocked for now -
Every component's availability is confirmed.
→ Payment opens.
purchase can continue
after payment
From one purchase to every backend
- 1PaymentOnly opens once availability is confirmed for every component.
- 2Booking requestsA booking-request queue routes each component's fulfilment to its own backend. It is a booking queue, not a payment queue.
- 3Error step codesFailures before booking are retried; errors a provider manages are left to the provider.
- 4Around the aggregationRetries, circuit breakers and caching sit around it, so one slow component does not stall the rest.
- 5Manual reviewFulfilment that cannot be recovered goes to customer experience for manual review.
duplicates
Check before retrying
Before a retry I look at the last N bookings, N being the package size, for a matching item and date. It reduces duplicates; it is a heuristic, not an idempotency guarantee.
ownership
Who did what, and when
- component endpoints already exist
- aggregation and flow designed
- builtfrontend and BFF
- in production
- MeDesigned and built the frontend and the BFF/backend aggregation
- The partnerProvided the substitutions; stays anonymous
- The backend teamOwned the existing component endpoints; created no new provider or database endpoints for this
- Success rateNot measured; the exception rate is unknown
What shipped
Combined travel-package flow in production for an anonymous partner.
no manual exception was reported to me; that is not a measured success rate- Delivered the combined travel-package flow to production for an anonymous partner.
Method and caveats
No manual exception was reported to me, which is not a measured success rate. The partner stays anonymous.
- Scope: I designed and built the frontend and the BFF/backend aggregation; the component endpoints already existed
- Delivery: in production for an anonymous partner
- Recovery mechanics: my own account; queue and provider names are not known here
- The package and the situations above are a reconstruction