Price Observation & Event Model

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

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.