---
title: "Price Observation & Event Model"
description: "Model travel pricing as timestamped observations and change events instead of only overwriting mutable current-price state."
slug: "price-observation-event-model"
translationKey: "architecture-price-observation-event"
locale: "en"
type: "guide"
category: "architecture"
tags: ["price","observation","event","freshness","analytics"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

A price-observation model answers more than “what is the current price?” It preserves **when, from which source and under which context that price was observed**.

## Production scenario

The same offer is observed at EUR 180, 195 and 182 during one day. If the system only overwrites current_price, it loses evidence needed for volatility, stale detection and incident analysis.

## Architecture flow

```text
Provider Response
 -> Normalize Offer Identity
 -> Normalize Price Components
 -> Create PriceObservation
 -> Persist Append-Only Event
 -> Update Current Snapshot
 -> Emit Change Event
 -> Analytics / Alert / Cache Invalidation
```

## Data model

Store observation ID, offer fingerprint, provider, search-context hash, observed/source timestamps, base/tax/fee/total components, currency, availability and raw source reference.

Maintain CurrentPriceSnapshot separately as materialized state.

## When to emit change events

You may persist every observation but only emit business-significant events when total price, availability, room/rate identity or tax/fee composition changes.

## Trade-offs

Keeping every observation forever costs storage. Keeping only the current snapshot destroys historical evidence.

A hot/cold strategy can retain detailed short-term observations and long-term aggregates.

## Deduplication

Retries can process the same provider response twice. Observation or event keys should support idempotent processing.

## Freshness semantics

observedAt, receivedAt and sourceUpdatedAt are different timestamps. Preserving each is critical for stale-price analysis.

## Failure modes

Typical issues include duplicate events, out-of-order updates, timezone mistakes, confusing FX-converted values with originals, losing tax components and allowing old events to overwrite newer snapshots.

## Concurrency

Use event versions or observedAt ordering when updating current state. A late older event must not roll state backwards.

## Observability

Track observation throughput, duplicates, out-of-order events, price-change frequency, freshness lag, snapshot/event divergence and alert volume.

## Alternatives

At low volume, an append-only table plus a current-state view can be sufficient. At high volume, stream processing, compacted topics and analytical storage can scale better.

## Production checklist

Use immutable observations, separate current snapshot, explicit timestamps, idempotency keys, ordering rules, preserved price components, retention policy and explicit change-event semantics.