Skip to main content

Performance and reliability

Edge Connect creates one place to add speed and safety services around native supplier adapters. The common foundation provides tenant-scoped state and request correlation; each adapter activates the services that fit its supplier protocol, data volatility, and commercial rules.

This page describes the services the platform can apply as native adapters come online. A Foundation label means the shared Edge Connect design provides the underlying capability. A Per connector label means the service is enabled only after supplier-specific behaviour and acceptance criteria are verified.

Supplier session reuse

Foundation

Store a valid supplier session with its expiry and tenant context. Native adapters can reuse it instead of performing avoidable authentication work on every request.

Duplicate-submission protection

Foundation

Record the result of a booking action against a tenant-scoped idempotency key. A repeated submission can return the stored result instead of creating another supplier booking.

Supplier response caching

Per connector

Cache eligible responses when the supplier permits it, the expected hit rate is useful, and the accepted staleness is clear. Cache policy can differ by operation rather than applying to every response.

Booking reconciliation

Per connector

Track progress through supplier updates and align Kaptio booking state when the provider exposes a suitable change feed or retrieval operation.

Request correlation and bounded metrics

Foundation

Carry one correlation identifier across the facade path and measure route, status, and duration without using guest details or unbounded supplier values as metric labels.

How these services improve the journey

The performance model combines several targeted improvements rather than depending on one cache:

ServiceCustomer effectSafety boundary
Session reuseAvoids repeated supplier authentication latency where sessions remain valid.Sessions are scoped by tenant and supplier, and renewed after expiry.
Response cachingCan reduce repeat search or reference-data latency for eligible operations.Time to live, cache key, and staleness tolerance are set per connector and operation.
Duplicate protectionMakes retries safer when a user or network repeats a booking submission.The idempotency record includes tenant and operation context, and does not merge unrelated requests.
ReconciliationIdentifies supplier-side changes without relying on a user to rediscover them manually.Progress is recorded per connector, and only supported supplier changes are applied.

These services share one implementation boundary with the native adapter. Kaptio can add or tune a service for that connector without changing the Salesforce workflow or introducing a different client contract.

Caching is selective by design

Travel data does not have one safe freshness policy. Static reference data, session metadata, and a live availability response have different volatility and supplier rules.

Edge Connect therefore makes caching a connector and operation decision:

  1. Identify an operation where reuse is permitted and useful.
  2. Define a bounded cache key that includes tenant and all inputs that affect the response.
  3. Agree the maximum acceptable staleness and time to live.
  4. Measure hit rate, miss rate, latency, and supplier-call reduction.
  5. Verify that booking, pricing, and availability correctness is unchanged.

If those conditions are not met, the adapter calls the supplier. The platform creates room for more caching without turning every supplier response into cached data.

Duplicate protection focuses on booking actions

A search can usually be repeated safely. A booking action may create a financial or operational commitment at the supplier.

For operations that can create or change a booking, Edge Connect can persist an idempotency result:

  • the first request performs the supplier action and records its outcome,
  • a retry with the same key and operation context returns that outcome,
  • a different tenant or materially different request cannot reuse the record,
  • expired records are removed according to the connector's retention policy.

This protects against duplicate submissions caused by browser retries, client timeouts, or uncertain network outcomes. It does not hide a genuine supplier failure; the stored status remains explicit.

Measured per connector

Performance services are introduced with measurable acceptance criteria. Depending on the connector, these can include:

  • supplier authentication calls avoided through session reuse,
  • cache hit and miss rate for eligible operations,
  • supplier calls avoided without stale booking results,
  • duplicate booking actions prevented,
  • reconciliation lag and completion rate,
  • end-to-end latency and supplier error rate.

The measurements determine whether a service is helping in production. A service that produces little reuse or unacceptable staleness is changed or disabled for that connector.