Ödeme Gözlemlenebilirlik ve Korelasyon (Odeme Gozlemlenebilirlik Ve Korelasyon)

Önceki bölümde webhook ile senkron yolun aynı kayda yarıştığını ve version token ile lease'in bunu nasıl çözdüğünü gördük. Peki yarış gerçekleştiğinde veya bir ödeme saatlerce FinalizePending'de kaldığında bunu nasıl görürsünüz?

Dağıtık bir ödeme sisteminde 'bir şeyler ters gitti' demek yetmez; hangi payment id, hangi adımda, hangi kanıtla takıldı sorusunun saniyeler içinde cevaplanması gerekir. Observability burada lüks değil — reconciliation worker'ın neyi tarayacağını, on-call mühendisinin hangi runbook'u açacağını belirleyen altyapıdır.

Payment #8812
  ├─ trace: checkout-orchestrator
  ├─ step log: ChargeSent → WebhookReceived → FinalizeAttempted
  └─ metric: deferred_finalize_age_seconds = 847

Bu bölüm, payment id'yi omurga yaparak log, trace ve metrikleri nasıl bir araya getireceğinizi ele alıyor.

Kavramlar ilk geçtiği yerde

📦 Payment ID (Correlation Spine)
Tüm servisler, loglar ve metriklerde tekrarlanan, ödeme yaşam döngüsünün birincil anahtarı.

📦 Step Event Log
Bir ödemenin her anlamlı adımını kaydeden, append-only olay dizisi.

📦 Deferred Finalize
Ödeme PSP tarafında sonuçlanmış olabilir ama local sistem henüz terminal statüye geçmemiştir.

📦 Structured Log
Serbest metin yerine alan tabanlı, sorgulanabilir log kaydı.

Request id veya trace id geçicidir; payment id kalıcıdır. Bir müşteri şikayeti geldiğinde aradığınız şey request id değil, payment id'dir.

Payment id: korelasyonun omurgası

Checkout orchestrator bir ödeme başlattığında payment id üretilir ve o andan itibaren her servise taşınır: provider gateway'e giden charge isteğinde, webhook metadata'sında, step event log'unda, metrik etiketlerinde. Bu id, dağınık izleri tek bir hikâyeye bağlar.

❌ Korelasyonsuz
  [ERROR] webhook processing failed
  [ERROR] charge timeout in gateway
  → hangi ödeme?

✓ Payment id ile
  paymentId=8812 step=WebhookReceived error=version_conflict
  paymentId=8812 step=ChargeSent latency_ms=4200
  → aynı ödeme, farklı adımlar, anında görünür

Trace span'leri de payment id taşımalıdır. Bir trace'e girdiğinizde checkout'tan webhook finalize'a kadar tüm adımları görmelisiniz — farklı servisler arasında request id değişse bile payment id sabit kalır.

Step event log: ödemenin zaman çizelgesi

Metrikler 'kaç tane' sorusuna cevap verir; step event log 'ne oldu, sırayla' sorusuna. Her anlamlı adım bir kayıt üretir:

8812  ChargeRequested      orchestrator   amount=249.00
8812  ChargeSent           gateway        providerRef=ch_abc
8812  SyncResponsePending  orchestrator   redirectUrl=issued
8812  WebhookReceived      gateway        event=PaymentCaptured
8812  FinalizeAttempted    orchestrator   version=3→4
8812  FinalizeSucceeded    orchestrator   status=Captured

Bu log append-only'dir; bir adım geri alınmaz, yeni bir adım eklenir. Telafi (compensation) veya reconciliation müdahalesi de kendi adımını yazar — böylece 'bu ödeme neden iki kez finalize edildi' sorusunun cevabı kaybolmaz.

Step event log, audit trail ile karıştırılmamalıdır: audit 'kim ne yaptı' sorusuna cevap verir; step log 'sistem ne yaptı, hangi sırada' sorusuna. İkisi birbirini tamamlar.

Deferred finalize metrikleri: sessiz takılmayı görünür kılmak

FinalizePending statüsünde kalan bir ödeme, müşteriye henüz sonuç gösterilmemiş ama PSP tarafında çoktan sonuçlanmış olabilir. Bu pencere normaldir — ama ne kadar sürdüğü ölçülmelidir.

Metrik: deferred_finalize_count
  → şu an FinalizePending'de olan ödeme sayısı

Metrik: deferred_finalize_age_seconds (histogram)
  → her ödemenin bu statüde ne kadar kaldığı

Alert: deferred_finalize_age_p99 > 600s
  → finalize pipeline'ında sistemik sorun

Bu metrikler reconciliation worker'ın 'ne kadar acil' taraması gerektiğini de belirler. deferred_finalize_age_seconds yükseliyorsa sorun tek bir ödemede değil, finalize pipeline'ında veya webhook işlemede olabilir.

Dashboard düzeni: operasyonel görünürlük

Panel	Gösterdiği	Aksiyon tetikleyicisi
Deferred finalize count	Takılı ödeme hacmi	Sürekli yükseliş → pipeline incelemesi
Finalize age P99	En kötü gecikme	SLA aşımı → on-call
Step log gap	Eksik adım (WebhookReceived yok)	Webhook delivery sorunu
Version conflict rate	Yarış yoğunluğu	Concurrency tuning

Sık karıştırılan ayrımlar

❌ Request id yeterli korelasyon sağlar
✓ Request id geçicidir; payment id ödeme boyunca kalıcıdır

❌ Log volume = observability
✓ Sorgulanabilir, payment id'li structured log = observability

❌ Metrikler geliştirme için yeterli
✓ Step event log, metriklerin gösteremediği sıra ve bağlamı taşır

Log vs step event log vs audit

Tür	Soru	Örnek
Structured log	Anlık olay detayı	WebhookReceived, latency=120ms
Step event log	Yaşam döngüsü sırası	ChargeSent → WebhookReceived → Finalize
Audit log	İnsan/süreç müdahalesi	Operator X triggered manual heal

Observability kontrol listesi

1. Her log satırı, trace span'i ve metrik etiketi payment id taşıyor mu?
2. Step event log append-only mi ve her anlamlı adımı kapsıyor mu?
3. deferred_finalize_count ve deferred_finalize_age_seconds metrikleri tanımlı mı?
4. Finalize age P99 için SLA tabanlı alert var mı?
5. Bir payment id ile step log'dan checkout'tan terminal statüye kadar tam yol izlenebiliyor mu?
6. Reconciliation worker'ın düzelttiği kayıtlar step log'a yazılıyor mu?

Bu yazıdan aklında ne kalmalı

1. Payment id, tüm observability'nin omurgasıdır; request id tek başına yetmez.
2. Step event log, ödemenin zaman çizelgesidir; metriklerin gösteremediği sırayı taşır.
3. Deferred finalize metrikleri, sessiz takılmayı ölçülü ve uyarılabilir kılar.
4. Observability lüks değil; reconciliation ve on-call'in neye bakacağını belirler.

Bir ödeme takıldığında 'loglara bakalım' yetmez; payment id ile saniyeler içinde hangi adımda kaldığını gösterecek bir step event log ve deferred finalize metriği gerekir.

Bir sonraki bölümde bu görünürlüğün üzerine recovery pipeline ve runbook'ları inşa ediyoruz: otomasyon önce, insan müdahalesi uniqueness duvarlarında.