---
title: "Offer Identity ve Offer Fingerprint Tasarımı"
description: "Travel offer'larını provider, room/rate, policy, price ve context boyutlarıyla deterministik biçimde tanımlayan offer fingerprint modelini tasarlayın."
slug: "offer-fingerprint-design"
translationKey: "architecture-offer-fingerprint"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["offer","fingerprint","identity","pricing","deduplication"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

Offer fingerprint'ın amacı kullanıcıya görünen her fiyatı kalıcı bir booking ID sanmak değil, **aynı ticari offer'ı aynı arama bağlamı içinde tekrar tanıyabilmek** için deterministik bir kimlik üretmektir.

## Production senaryosu

Aynı hotel, oda ve rate plan iki provider response'unda farklı field sırası, farklı currency precision veya farklı marketing text ile gelebilir. Aynı zamanda refundable ve non-refundable ürünler aynı room adı altında bulunabilir.

## Mimari akış

```text
Raw Provider Offer
 -> Normalize Search Context
 -> Normalize Property / Room / Rate Identity
 -> Normalize Commercial Terms
 -> Select Fingerprint Fields
 -> Canonical Serialize
 -> Stable Hash
 -> Persist Fingerprint + Source Reference
```

## Fingerprint'e hangi alanlar girmeli?

Tipik alanlar:

- canonical property ID,
- canonical room ID veya room signature,
- rate-plan signature,
- meal/board basis,
- refundability/cancellation class,
- payment timing,
- occupancy,
- stay dates,
- market/residency context gerektiğinde,
- original currency,
- provider/source identity.

Price amount çoğu zaman fingerprint'e doğrudan dahil edilmemelidir; aksi halde her fiyat değişimi yeni offer identity üretir.

## Data model

```text
OfferFingerprint
- fingerprint
- provider
- canonicalPropertyId
- roomSignature
- rateSignature
- contextHash
- sourceOfferRef
- firstSeenAt
- lastSeenAt
```

Fingerprint ile source offer reference aynı şey değildir. Booking/reprice için source reference korunmalıdır.

## Tasarım trade-off'ları

Çok az alan kullanırsanız farklı ürünler merge olur. Çok fazla alan kullanırsanız aynı ticari ürün gereksiz yere parçalanır.

Özellikle free-text room name, dynamic promotion label ve localized description fingerprint alanı olmamalıdır.

## Collision ve determinism

Canonical serialization field ordering, null handling, enum normalization ve Unicode normalization açısından deterministik olmalıdır.

Hash collision teorik olarak mümkündür; kritik sistemlerde fingerprint'in yanında canonical key payload veya component digest saklamak debug açısından faydalıdır.

## Failure modes

- refundable/non-refundable merge,
- meal plan farkının kaybolması,
- provider source ID'nin düşmesi,
- fiyatı identity'ye dahil edip churn yaratma,
- occupancy context'ini unutma,
- localized text yüzünden unstable hash.

## Cache ve lifecycle

Fingerprint stable identity sağlar ama offer freshness'i garanti etmez. Price observation ve current availability ayrı state olarak tutulmalıdır.

## Observability

- duplicate merge rate,
- fingerprint churn,
- collision suspicion,
- same-fingerprint price volatility,
- unmapped room/rate ratio,
- booking/reprice lookup success.

## Alternatifler

Provider zaten güçlü ve stable offer ID veriyorsa bunu source identity olarak kullanın; yine de cross-provider dedup için normalized fingerprint gerekebilir.

## Production checklist

- explicit field list
- canonical serialization
- context hash
- source reference preservation
- no free-text dependency
- no raw price in identity unless business rule requires it
- collision diagnostics
- fingerprint versioning