---
title: "Booking Lifecycle Event Model"
description: "Travel booking state'ini create, confirm, modify, cancel, fail ve reconcile event'leriyle izleyen lifecycle modelini tasarlayın."
slug: "booking-lifecycle-event-model"
translationKey: "architecture-booking-lifecycle-event"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["booking","event","lifecycle","reconciliation","idempotency"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "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.

## Production checklist

- immutable event log
- explicit transition rules
- idempotency
- ordering/version strategy
- unknown state
- separate payment lifecycle
- reconciliation job
- audit trail
- replay tooling