E-ticaret Ödeme akışı Dayanıklılığı: PostgreSQL, Redis, Yedek ve Olay Rehberi

Ödeme akışıta hız kadar tekrar denenebilirlik de önemlidir

Kullanıcı ödeme butonuna bastığında ağ kopabilir, ödeme sağlayıcı geç cevap verebilir, uygulama retry yapabilir veya kullanıcı sayfayı yenileyebilir. Bu yüzden ödeme akışı tasarımı “tek sefer çalışırsa” değil, “aynı niyet birden fazla kez gelirse” ne olur sorusuyla tasarlanmalıdır.

Veritabanı tarafında bunun karşılığı idempotency, transaction sınırı ve durum makinesidir. Sepet hızlı olabilir, stok dikkat ister, ödeme sonucu ise kanıtlanabilir olmalıdır.

Sepet geçici olabilir ama sipariş kalıcı ve izlenebilir olmalıdır.
Ödeme isteği idempotency key ile takip edilmelidir.
Stok rezervasyonu belirli süreli ve geri alınabilir olmalıdır.
Sipariş durumu tek bir açık state machine ile ilerlemelidir.

PostgreSQL kalıcı gerçeği tutar

Ödeme akışı akışında sipariş, ödeme niyeti, ödeme sonucu ve stok hareketi kalıcı gerçeğin parçasıdır. Bunlar sadece Redis’te tutulmamalı; Redis hız için, PostgreSQL doğruluk için kullanılmalıdır.

Idempotency key benzersiz indeksle korunursa aynı ödeme isteği tekrar geldiğinde sistem ikinci sipariş oluşturmak yerine mevcut işlemi döndürür.

Ödeme idempotency tablosu

checkout-idempotency.sql

CREATE TABLE payment_attempts (
  id bigserial PRIMARY KEY,
  tenant_id uuid NOT NULL,
  order_id uuid NOT NULL,
  idempotency_key text NOT NULL,
  status text NOT NULL CHECK (status IN ('pending', 'succeeded', 'failed')),
  provider_ref text,
  created_at timestamptz NOT NULL DEFAULT now(),
  updated_at timestamptz NOT NULL DEFAULT now(),
  UNIQUE (tenant_id, idempotency_key)
);

Redis hızlandırır ama sahip olmadığı sorumluluğu almamalı

Sepet, kampanya önbelleği ve kısa süreli stok rezervasyonları Redis için uygundur. Ama Redis içindeki veri kaybolduğunda ne olacağını önceden düşünmelisiniz. Sepet tekrar oluşturulabilir mi? Stok rezervasyonu süresi dolunca ne olur?

Önbellek stampede ve TTL eksikliği ödeme akışı dönemlerinde ana veritabanını gereksiz yorabilir. Özellikle kampanya ve fiyat bilgisi keylerinde jitter ve stale stratejisi düşünülmelidir.

Sepet ve rezervasyon keyleri

checkout-redis-keys.txt

cart:{tenant}:{user}              -> TTL 7 gün, kullanıcı deneyimi
stock_reservation:{tenant}:{sku} -> TTL 10 dakika, geri alınabilir niyet
campaign:{tenant}:{campaign_id}  -> TTL + jitter, ana DB koruması
payment_lock:{order_id}          -> kısa TTL, çift işlem önleme

Yedek kararı ödeme akışı sırasında verilmez

Ödeme akışı olayında “geri yükleme edelim mi?” sorusu en pahalı sorulardan biridir. Çünkü geri yükleme, sadece veriyi geri almak değil, ödeme sağlayıcı, sipariş durumu, kargo ve müşteri bildirimleriyle tutarlılık demektir.

Bu yüzden PITR penceresi, geri yükleme tatbikatı ve ödeme mutabakatı önceden planlanmalıdır. Her veri bozulması geri yükleme ile çözülmez; bazen düzeltme scripti ve denetim daha doğru yoldur.

Kampanya öncesi TürkDB kontrolü

checkout-preflight.sh

turkdb cluster get commerce-pg
turkdb cluster get commerce-redis
turkdb backup create commerce-pg
turkdb cluster pitr window commerce-pg
turkdb cluster slow-queries commerce-pg --threshold 200 --limit 20

Bu TürkDB bloğu kavramsal ürün akışını anlatır; mevcut çalışan komut, garanti edilen özellik veya teslim tarihi vaadi olarak okunmamalıdır.

Olay müdahale rehberi müşteri etkisiyle başlar

Ödeme akışı yavaşladığında ilk soru CPU kaç değil, kaç kullanıcı ödeme tamamlayamıyor olmalıdır. Teknik sinyaller önemlidir ama öncelik müşteri etkisidir. Ödeme tamamlandı mı, sipariş oluştu mu, stok düştü mü, kullanıcı tekrar deneyebilir mi?

TürkDB olayları ve metrikleri altyapı fotoğrafını verir. Uygulama tarafında ise ödeme akışı state machine ve ödeme sağlayıcı kayıtlarıyla bu fotoğraf birleştirilmelidir.

E-ticaret ödeme akışı dayanıklılığı: PostgreSQL, Redis ve yedek planı birlikte nasıl düşünülür?