Java Developer Career in the Travel Industry

// Search — parallel supplier calls.
// The core of any OTA search engine: query many suppliers at once.

import java.util.List;
import java.util.concurrent.*;

public class FlightSearchService {

    private final List<SupplierClient> suppliers;
    private final ExecutorService executor;

    public FlightSearchService(List<SupplierClient> suppliers) {
        this.suppliers = suppliers;
        this.executor = Executors.newFixedThreadPool(8);
    }

    public List<Flight> search(SearchRequest request) throws Exception {
        // Submit each supplier call as a CompletableFuture
        List<CompletableFuture<List<Flight>>> futures = suppliers.stream()
            .map(supplier -> CompletableFuture.supplyAsync(() -> {
                try {
                    return supplier.search(request);
                } catch (Exception e) {
                    // One failing supplier should not fail the whole search
                    return List.<Flight>of();
                }
            }, executor))
            .toList();

        // Wait for all, with a timeout
        CompletableFuture<Void> allDone = CompletableFuture.allOf(
            futures.toArray(new CompletableFuture[0])
        );

        try {
            allDone.get(2500, TimeUnit.MILLISECONDS);
        } catch (TimeoutException e) {
            // Return whatever finished; cancel the rest
            futures.forEach(f -> f.cancel(true));
        }

        // Aggregate results
        return futures.stream()
            .filter(CompletableFuture::isDone)
            .filter(f -> !f.isCompletedExceptionally())
            .flatMap(f -> f.join().stream())
            .sorted((a, b) -> a.price().compareTo(b.price()))
            .toList();
    }
}

// What this teaches:
// - Parallel calls with CompletableFuture
// - Timeout handling — a slow supplier must not block the user
// - Partial failure tolerance — one bad supplier should not fail everything
// - Aggregation and sorting as the final step

// Why it matters in travel:
// Users expect search results in under 2 seconds.
// With 10+ suppliers, you cannot call them sequentially.
// The best engineers make search fast AND resilient.

// Booking — idempotent create.
// Users retry. Networks fail. The same booking must not be created twice.

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class BookingService {

    private final BookingRepository bookings;
    private final BookingIdempotencyStore idempotency;
    private final SupplierClient supplier;

    public BookingService(BookingRepository bookings,
                          BookingIdempotencyStore idempotency,
                          SupplierClient supplier) {
        this.bookings = bookings;
        this.idempotency = idempotency;
        this.supplier = supplier;
    }

    @Transactional
    public BookingResponse createBooking(CreateBookingRequest request,
                                         String idempotencyKey) {

        // 1. Check if this exact request was already processed
        var existing = idempotency.find(idempotencyKey);
        if (existing.isPresent()) {
            return existing.get();  // return the same response
        }

        // 2. Call the supplier — this is where real bookings happen
        SupplierBookingResult supplierResult =
            supplier.book(request.flightId(), request.passenger());

        if (!supplierResult.confirmed()) {
            throw new BookingFailedException(supplierResult.reason());
        }

        // 3. Persist locally
        Booking booking = Booking.create(
            request,
            supplierResult.supplierReference()
        );
        bookings.save(booking);

        // 4. Cache the response against the idempotency key
        BookingResponse response = BookingResponse.from(booking);
        idempotency.store(idempotencyKey, response);

        return response;
    }
}

// What this teaches:
// - Idempotency keys — the standard pattern for retriable operations
// - Transactional boundaries in booking flows
// - The order: check cache → call supplier → persist → cache response

// Why it matters in travel:
// A failed retry that creates a duplicate booking costs the
// company real money (refunds, penalties) and destroys trust.
// The idempotency key is the standard fix.

// Payment — saga with compensations.
// A booking involves multiple steps: charge card, confirm supplier,
// reserve inventory. If any step fails, prior steps must undo.

import org.springframework.stereotype.Service;

@Service
public class BookingSaga {

    private final PaymentService payments;
    private final SupplierClient supplier;
    private final InventoryService inventory;

    public BookingSaga(PaymentService payments,
                       SupplierClient supplier,
                       InventoryService inventory) {
        this.payments = payments;
        this.supplier = supplier;
        this.inventory = inventory;
    }

    public BookingResult execute(BookingRequest request) {

        String paymentId = null;
        String supplierRef = null;
        String inventoryHold = null;

        try {
            // Step 1: Hold inventory
            inventoryHold = inventory.hold(request.flightId(), request.passenger());

            // Step 2: Charge the customer
            paymentId = payments.charge(request.amount(), request.card());

            // Step 3: Confirm with the supplier
            supplierRef = supplier.confirm(request.flightId(), request.passenger());

            // All three succeeded — finalise
            inventory.commit(inventoryHold);
            return BookingResult.success(supplierRef, paymentId);

        } catch (PaymentFailedException e) {
            // Supplier not yet called — just release the hold
            if (inventoryHold != null) inventory.release(inventoryHold);
            throw e;

        } catch (SupplierFailedException e) {
            // Refund the payment, release the hold
            if (paymentId != null) payments.refund(paymentId);
            if (inventoryHold != null) inventory.release(inventoryHold);
            throw e;

        } catch (Exception e) {
            // Unknown failure — undo everything that succeeded
            if (supplierRef != null) supplier.cancel(supplierRef);
            if (paymentId != null) payments.refund(paymentId);
            if (inventoryHold != null) inventory.release(inventoryHold);
            throw e;
        }
    }
}

// What this teaches:
// - The Saga pattern — the standard way to handle distributed
//   transactions without a global lock
// - Compensation on every failure path
// - The order matters: hold → charge → confirm → commit

// Why it matters in travel:
// Without compensation, a failed booking leaves the user
// charged with no flight, or the inventory held forever.
// That is a real-world disaster — and it is the kind of
// thing travel interviews probe directly.