Performance

An honest guide to what's fast, what's slow, and where the platform keeps system-of-record work out of the browse-and-build path. Final booking creation currently reaches Salesforce synchronously, so it is intentionally listed as a separate latency class.

Latency classes

Every endpoint falls into one of three classes:

Class	Typical latency	Endpoints	Why
Cached reads	tens of milliseconds	GET /config, GET /catalog/trips, GET /catalog/categories	Served from the Journeys catalog cache, warmed in the background
Platform compute	hundreds of milliseconds to ~2s	GET /catalog/rooms, basket operations, GET /prices, GET /payment-schedules, promotion checks	Live KTAPI pricing/availability computation — real inventory, real pricing engine, no Salesforce round-trip in the request path
System-of-record writes	seconds	POST /bookings	Creates the itinerary in Salesforce — the one step that must touch the org synchronously today

Two design consequences:

• The browse-and-build experience does not touch Salesforce. Catalog, room/cabin inventory, pricing, promotions, and payment schedules are served by KTAPI and Basket Service. A guest configures an entire trip without a Salesforce round-trip.
• Salesforce work is concentrated in exactly one guest-facing moment: final checkout. Everything around it is engineered so that moment is either fast enough or moved off the guest's critical path entirely (see below).

How the platform keeps guests off the slow path

Catalog caching and background warming. Trip/departure/from-price data is aggressively cached and refreshed in the background. Cruise cabin inventory and touring room-option pricing use different KTAPI reads but share the same cache boundary.

Parallel fan-out. Where multiple upstream calls are needed (per-currency pricing, per-package loads), the platform issues them concurrently — response time follows the slowest call, not the sum.

Inventory holds decouple selection from booking. When a guest selects an inventory-backed room or cabin, the platform carries the applicable hold into checkout. The subsequent traveller entry, pricing review, and payment steps do not need to repeat the final Salesforce write.

Current checkout is synchronous. POST /baskets/:id/bookings waits for itinerary creation and returns the booking reference. That is the only booking-creation route in the current public contract.

Asynchronous checkout is an extension pattern. A deployment can move booking creation behind a queue and deliver the final reference by webhook, but this must be explicitly enabled and contracted; it is not a second public endpoint documented today. The intended sequence is:

1. Take payment against the basket (payment-requests — no Salesforce dependency).
2. Show the guest immediate confirmation with the basket reference.
3. Create the booking asynchronously; deliver the final booking reference via booking.created webhook — to the confirmation page, email, or workbench.

When enabled, the guest's perceived checkout time becomes the payment time and booking creation happens behind the confirmation screen. Without that extension, clients must wait for the synchronous booking response.

Existing-itinerary lifecycle is separate. The platform has pricing, cancellation-rule, and orchestration primitives that can support amendments, cancellations, and refunds, but the public Journeys API does not currently expose execution routes for them. Performance characteristics must be documented when those routes are added rather than inferred from booking creation.

Touring catalog considerations

Touring from-prices and room availability are resolved from required PriceCategories package options rather than cruise-detail and physical-cabin calls. That option pricing is heavier, so the live provider bounds concurrent departure enrichment and relies on warming. Treat the latency classes as targets to verify against the tenant's departure count and option structure, not as a guarantee that every cold touring catalog call completes in the same time as a cruise catalog call.

In-country deployment

Latency classes above assume the client is in the same region as the platform. Where a market requires it, the full Edge stack — Journeys, KTAPI, Basket Service — deploys into in-country infrastructure alongside the tenant's Salesforce environment, so the latency classes hold for local guests rather than being degraded by intercontinental round-trips. In-country endpoints are assigned during onboarding.

What to measure

Every tenant gets per-tenant, per-channel operational metrics (request rates, latency, basket and booking counters). During private beta onboarding we baseline the latency classes above against your actual catalog size and org, and agree targets — rather than quoting universal numbers that ignore catalog shape, org customization, and region.