---
title: "Travel Observability, Trace and Correlation Model"
description: "Trace travel transactions from search through booking and servicing using correlation IDs, distributed traces, metrics and structured domain events."
slug: "travel-observability-trace-correlation-model"
translationKey: "architecture-travel-observability-trace-correlation"
locale: "en"
type: "guide"
category: "architecture"
tags: ["observability","trace","correlation","metrics","booking","travel"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
---

Observability in travel is more than HTTP latency charts. The goal is to **follow the evidence chain from a search request through confirmed booking, payment and servicing outcomes**.

## Correlation chain

```mermaid
%% title: Travel transaction correlation chain
%% description: Search, offer, booking, payment and provider execution identifiers are connected in one traceable chain.
flowchart LR
  A[searchId] --> B[offerId / offerVersion]
  B --> C[bookingIntentId]
  C --> D[bookingAttemptId]
  C --> E[paymentAttemptId]
  D --> F[providerReference]
  F --> G[bookingId]
  G --> H[servicingAttemptId]
```

## Identity layers

Preserve trace ID, search ID, offer ID/version, booking intent ID, booking attempt ID, payment attempt ID, canonical booking ID, provider booking reference and servicing attempt ID. Do not collapse them into one identifier.

## Structured events

Emit domain events for important transitions and include correlation IDs, state change, evidence source and provider reference. Do not place PII in event payloads.

## Metrics hierarchy

Track search provider health, offer/reprice freshness, booking confirmation/UNKNOWN/reconciliation, payment authorization/capture/refund, and servicing completion/manual intervention.

## Trace spans

Represent provider calls as separate spans with adapter, operation, provider, timeout budget and outcome classification. Avoid raw request/response bodies in traces because they can leak sensitive data.

## Logs vs events vs metrics

Logs serve debugging, events preserve domain evidence, metrics aggregate trends, and traces represent causal request chains. Design schemas by purpose rather than duplicating uncontrolled payloads everywhere.

## SLOs

Define business SLOs for search completion, booking confirmation, UNKNOWN resolution, reconciliation age and servicing completion, not only infrastructure uptime.

## Alerting

Useful alerts include provider p95 latency spikes, aging UNKNOWN backlog, payment/booking divergence, duplicate-booking signals, webhook signature failures and reconciliation queue growth.

## Failure modes

Broken provider-reference correlation, PII in logs, high-cardinality metric labels, losing failed traces to sampling, clock skew and inconsistent state vocabularies.

## Production checklist

Use canonical correlation IDs, structured domain events, provider spans, PII redaction, metric-cardinality limits, business SLOs, biased retention for errors/UNKNOWN outcomes, searchable provider references and consistent time standards.