Offer Identity & Offer Fingerprint Design

An offer fingerprint should not pretend every displayed fare is a permanent booking ID. Its purpose is to recognize the same commercial offer deterministically within a defined search context.

Production scenario

The same hotel room and rate plan can arrive from a provider with different field order, text labels or currency formatting, while refundable and non-refundable products can share the same room name.

Architecture flow

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

Fields to include

Typical inputs include canonical property ID, room signature, rate-plan signature, meal basis, refundability/cancellation class, payment timing, occupancy, stay dates, relevant market/residency context, original currency and provider/source identity.

The raw price amount usually should not be part of the fingerprint; otherwise every price update creates a new identity.

Data model

Persist fingerprint, provider, canonical property, room/rate signatures, context hash, source offer reference and first/last-seen timestamps.

Fingerprint and provider offer reference are different concepts. Preserve the source reference for repricing and booking.

Design trade-offs

Too few fields merge distinct products. Too many fields fragment one commercial product unnecessarily.

Avoid free-text room names, dynamic promotion labels and localized descriptions as identity inputs.

Determinism and collisions

Canonical serialization must define field ordering, null handling, enum normalization and Unicode behavior.

Hash collisions are unlikely but possible. For critical systems, retain canonical components or a debug payload beside the hash.

Failure modes

Common failures include merging refundable with non-refundable inventory, losing meal-plan differences, dropping provider source IDs, including price and causing identity churn, omitting occupancy, or hashing localized text.

Cache and lifecycle

A fingerprint provides stable identity but does not imply freshness. Current price and availability should live in separate observation/state models.

Observability

Track duplicate merges, fingerprint churn, suspected collisions, price volatility per fingerprint, unmapped room/rate ratios and repricing lookup success.

Alternatives

If a provider supplies a strong stable offer ID, keep it as source identity. A normalized fingerprint can still be useful for cross-provider deduplication.

Production checklist

Define explicit fields, canonical serialization, context hashing, source-reference preservation, fingerprint versioning and collision diagnostics. Avoid raw price and free-text dependencies unless required by the domain.