Booking Lifecycle Event Model

Travel booking state'ini create, confirm, modify, cancel, fail ve reconcile event'leriyle izleyen lifecycle modelini tasarlayın.

Editoryal bilgi

Hazırlayan: metasearch.com.trAI destekli araştırma ve taslakSon teknik/kaynak kontrolü: 2026-09-26

Booking lifecycle event model, rezervasyonu tek bir mutable status alanına indirgemek yerine hangi olayların hangi sırada gerçekleştiğini ve state'in hangi kanıttan türetildiğini saklar.

Production senaryosu

Booking create request timeout oluyor; provider rezervasyonu oluşturmuş olabilir. Daha sonra webhook CONFIRMED geliyor, ardından cancellation ve refund event'i oluşuyor. Tek status alanı bu sürecin audit trail'ini kaybeder.

Mimari akış

text

Booking Attempt
 -> CREATE_REQUESTED
 -> provider call
 -> CREATED / UNKNOWN / FAILED
 -> CONFIRMED
 -> MODIFIED?
 -> CANCEL_REQUESTED?
 -> CANCELLED?
 -> REFUND/SETTLEMENT?
 -> RECONCILED

Temel entity'ler

Booking
BookingAttempt
BookingEvent
ProviderBookingReference
PaymentReference
ReconciliationRecord

Event örneği

json

{
  "eventId": "evt-123",
  "bookingId": "bk-42",
  "type": "CONFIRMED",
  "provider": "supplier-a",
  "providerReference": "ABC123",
  "occurredAt": "2026-09-26T10:00:00Z",
  "receivedAt": "2026-09-26T10:00:02Z",
  "source": "webhook"
}

State türetme

Current booking state event history'den materialize edilmelidir. Her event geçerli bir transition üretmeyebilir.

Örneğin CANCELLED event'i CONFIRMED öncesi gelebiliyorsa out-of-order handling gerekir.

Idempotency

Webhook tekrarları normaldir. eventId, provider event key veya deterministic dedup key ile aynı event'in iki kez uygulanması engellenmelidir.

Unknown state

Timeout sonrası UNKNOWN first-class state olmalıdır. FAILED demek duplicate booking riskini artırır.

Unknown state lookup/reconciliation ile çözülmelidir.

Payment ile booking'i ayırın

Payment authorized olması booking confirmed anlamına gelmez. Booking ve payment lifecycle'ları ayrı state machine'ler olmalı, reconciliation katmanında bağlanmalıdır.

Failure modes

duplicate webhook,
out-of-order event,
provider reference değişimi,
payment/booking divergence,
cancellation confirm olmadan UI'da cancelled gösterme,
retry ile duplicate create.

Concurrency

Event processing optimistic version veya sequence ile korunmalıdır. Aynı booking üzerinde iki consumer paralel state update yapıyorsa deterministic ordering gerekir.

Observability

unknown booking age,
duplicate event rate,
out-of-order event rate,
booking/payment divergence,
reconciliation latency,
invalid transition count.

Alternatifler

Basit single-provider, düşük hacimli sistemde event table + materialized status yeterlidir. Tam event sourcing yalnız audit/replay ihtiyacı gerçekten varsa kullanılmalıdır.