---
title: "Price Observation ve Event Model"
description: "Travel fiyatlarını mutable current state yerine zaman damgalı observation/event kayıtlarıyla izleyen veri modelini tasarlayın."
slug: "price-observation-event-model"
translationKey: "architecture-price-observation-event"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["price","observation","event","freshness","analytics"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

Price observation model, “şu anki fiyat kaç?” sorusunun yanında **bu fiyat ne zaman, hangi context'te, hangi source'tan gözlendi?** sorusunu da cevaplayabilmek için tasarlanır.

## Production senaryosu

Aynı offer gün içinde 180, 195 ve 182 EUR olarak gözleniyor. Sistem yalnız current_price alanını overwrite ederse volatility, stale detection ve incident RCA için tarihsel kanıt kaybolur.

## Mimari akış

```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

```text
PriceObservation
- observationId
- offerFingerprint
- provider
- searchContextHash
- observedAt
- sourceUpdatedAt?
- baseAmount
- taxes
- fees
- totalAmount
- currency
- availability
- rawReference
```

CurrentPriceSnapshot ayrı materialized state olabilir.

## Event ne zaman üretilmeli?

Her response için observation yazabilirsiniz; change event ise business-significant değişiklikte üretilmelidir.

Örnek:
- total price changed,
- availability changed,
- room/rate identity changed,
- tax/fee composition changed.

## Trade-off

Her observation'ı sonsuza kadar saklamak storage maliyeti yaratır. Sadece current snapshot tutmak ise analytics ve RCA kabiliyetini kaybettirir.

Hot/cold retention uygulanabilir:
- kısa dönem detaylı observation,
- uzun dönem aggregate/min-max/percentile.

## Deduplication

Aynı provider response bir retry nedeniyle iki kez işlenebilir. observationId veya event key deterministik/idempotent tasarlanmalıdır.

## Freshness

observedAt, receivedAt ve sourceUpdatedAt aynı kavram değildir. Bunları ayırmak stale-price analizi için kritiktir.

## Failure modes

- duplicate event,
- out-of-order observation,
- timezone hatası,
- FX-converted price'ı original price sanma,
- tax component kaybı,
- current snapshot'ın eski event ile geriye alınması.

## Concurrency

Current snapshot update ederken event version veya observedAt ordering kullanılmalıdır. Geç gelen eski event daha yeni state'i overwrite etmemelidir.

## Observability

- observations/sec,
- duplicate rate,
- out-of-order rate,
- price-change frequency,
- freshness lag,
- snapshot/event divergence,
- alert volume.

## Alternatifler

Düşük hacimli sistemde append-only tablo + current view yeterli olabilir. Yüksek hacimde stream + compacted topic + analytical storage tercih edilebilir.

## Production checklist

- immutable observation
- separate current snapshot
- explicit timestamps
- idempotency key
- ordering/version rule
- price component preservation
- retention policy
- change-event semantics