Offer Identity ve Offer Fingerprint Tasarımı

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ış

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

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