Travel Booking Saga ve Compensation Patterns
Travel booking, payment, cancellation ve refund akışlarında rollback yerine Saga ve compensation desenlerini tasarlayın.
Travel booking distributed transaction'ı rollback edilemez. Supplier booking, payment capture, ticketing veya refund farklı sistemlerde gerçekleştiği için başarısızlık sonrası compensating action gerekir.
Saga flow
Travel booking Saga
Compensation rollback değildir
Booking cancel:
- fee doğurabilir,
- inventory'i aynı koşulla geri vermeyebilir,
- supplier'da async tamamlanabilir.
Refund:
- settlement sonrası gecikebilir,
- FX farkı yaratabilir,
- payment fee'lerini geri döndürmeyebilir.
Bu yüzden compensation outcome ayrıca izlenmelidir.
Orchestration vs choreography
Orchestration
Central Saga orchestrator hangi step'in sırada olduğunu bilir.
Avantaj:
- debugging kolay,
- explicit state,
- ops görünürlüğü yüksek.
Risk:
- orchestrator karmaşıklaşır.
Choreography
Servisler event'lerle birbirini tetikler.
Avantaj:
- loose coupling.
Risk:
- global flow'u anlamak zor,
- duplicate/out-of-order event etkisi büyür.
Travel booking için kritik financial workflow'larda explicit orchestration çoğu zaman daha okunabilirdir.
Saga step modeli
Her step:
- operation,
- status,
- forward action,
- compensation action,
- idempotency key,
- attempt count,
- last evidence,
- next retry time saklamalıdır.
Forward recovery mi compensation mı?
Capture fail olduysa hemen booking cancel etmek yerine:
- capture retry güvenli mi?
- alternate payment path var mı?
- traveler liability korunuyor mu?
- cancellation fee var mı?
- ops müdahalesi daha güvenli mi?
kararı verilmelidir.
Compensation matrix
| Forward step | Failure | Compensation |
|---|---|---|
| authorize | booking failed | void |
| capture | booking later cancelled | refund/void |
| booking confirmed | payment unrecoverable | cancel booking |
| ticket issued | servicing failed | provider-specific servicing |
| cancellation confirmed | refund failed | refund reconciliation |
UNKNOWN compensation
Original outcome UNKNOWN iken compensation da blind yapılmamalıdır. Örneğin booking UNKNOWN iken "cancel" göndermek, booking yaratılmadıysa anlamsız; yaratıldıysa doğru olabilir. Önce authoritative evidence toplanmalıdır.
Failure modes
- compensation'ın duplicate çalışması,
- compensation'ın kendisinin UNKNOWN olması,
- cancel fee'nin hesaba katılmaması,
- forward recovery mümkünken erken rollback,
- choreography event loop,
- partial compensation sonrası local state'in COMPLETED görünmesi.
Observability
- saga completion rate,
- compensation rate,
- compensation success/failure,
- forward recovery rate,
- manual intervention rate,
- time in RECOVERY_REQUIRED,
- compensation financial loss/cost.
Production checklist
- explicit Saga state,
- idempotent forward/compensation actions,
- compensation policy per provider,
- UNKNOWN-safe recovery,
- financial impact visibility,
- manual escalation,
- audit trail,
- replay-safe event handling.
Benzer bir entegrasyon mu planlıyorsunuz?
Gereksinim, feed/API tasarımı ve production yaklaşımını birlikte değerlendirebiliriz.