CQRS ve Materialized View

-- On kosul: ayni hesabin olaylari tek partition'dan, sirali gelir.

-- Inbox: anahtar sadece olay_id DEGIL, (tuketici, olay_id)
CREATE TABLE islenen_olaylar (
  tuketici  text,          -- 'portfoy_gorunum', 'risk_gorunum', 'portfoy_gorunum_v2'
  olay_id   text,
  islenme   timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (tuketici, olay_id)
);

-- FillGerceklesti olayi geldiginde, TEK ifade:
-- inbox satiri yazilmazsa delta da uygulanmaz.
WITH yeni AS (
  INSERT INTO islenen_olaylar (tuketici, olay_id)
  VALUES ('portfoy_gorunum', :olay_id)
  ON CONFLICT DO NOTHING
  RETURNING 1                             -- tekrar gelen olayda hic satir donmez
)
INSERT INTO portfoy_gorunum (hesap_id, sembol, net_lot, ort_giris, son_islem, surum)
SELECT :hesap, :sembol, :lot, :fiyat, :zaman, :olay_sirasi
 WHERE EXISTS (SELECT 1 FROM yeni)        -- yoksa INSERT hic calismaz
ON CONFLICT (hesap_id, sembol) DO UPDATE
   SET net_lot   = portfoy_gorunum.net_lot + EXCLUDED.net_lot,
       ort_giris = (...),
       son_islem = EXCLUDED.son_islem,
       surum     = EXCLUDED.surum;        -- filtre degil, sadece kayit

Dört ayrıntı, dördü de canımı yaktı.

Sürüm filtresi yok. İlk sürümde WHERE surum < EXCLUDED.surum vardı; “geç gelen eski olay görünümü bozamaz” diye yazmıştım. Yanlıştı. Bu tablo delta ile güncelleniyor (“300 lot eklendi”), mutlak durumla değil (“net lot artık 300”). Olay 5, olay 4’ten önce gelirse filtre 4’ü tamamen atar ve o fill’in lotu kaybolur. Görünüm bozulmuyor, eksik kalıyor; daha sinsi. Delta ile çalışıyorsan sıra pazarlık konusu değil: aynı hesabın olayları aynı partition’dan, aynı sırayla gelir. Sıra varsa filtre yine işine yarar — aşağıda.

Inbox’ın anahtarı (tuketici, olay_id). İlk yazdığımda anahtar sadece olay_id’ydi. Aynı fill olayı risk_gorunum’u ve gun_sonu_gorunum’u da besliyor; hepsi aynı inbox’a bakınca ilk davranan olayı “işlendi” diye işaretliyor, diğer ikisi tekrar sanıp atlıyor. Sessizce eksik iki görünüm. Aynı hata yeniden inşayı da öldürüyor: portfoy_gorunum_v2’ye geçmişi oynattığında bütün olay ID’leri zaten kayıtlı olduğu için v2 boş kalıyor. Her görünüm ve her sürümü kendi tüketici adıyla kendi kaydını tutar.

Kontrol yorumda değil, ifadenin içinde. Bunu da bir kez “önce inbox’a yaz, 0 satır dönerse atla” diye yorum satırıyla anlatmıştım. Yorum kodu durdurmuyor: ikinci INSERT koşulsuz çalışıyor ve delta iki kez ekleniyor — tam da engellemeye çalıştığın şey. Ya yukarıdaki gibi tek ifadeye indir, ya da dallanmayı uygulama kodunda açıkça yaz. Transaction da bu yüzden var: tek ifadeyi sarmak için değil, “işledim” kaydıyla güncellemeyi birlikte yazmak için.

olay_sirasi outbox’ın bigserial’i değil. O ID INSERT anında ayrılıyor, commit anında değil; 101 numaralı olay 100’den önce commit olabiliyor (outbox yazısında detayı var). Buradaki sıra hesap başına üretiliyor: fill’i yazan transaction, aynı anda hesap satırındaki sayacı bir artırıyor ve o değeri olaya koyuyor. Aynı hesaba yazan transaction’lar o satırın kilidinde serileştiği için sayaç monoton artıyor. Partition anahtarı da hesap; yani sıra hangi anahtar için garanti ediliyorsa, sayaç da o anahtar için artıyor. İkisi aynı anahtar değilse garanti yok demektir.

Dürüst cevap: sıra garantin varsa şart değil. Sıra varsa at-least-once’tan gelen tekrarlar her zaman zaten uygulanmış olayların tekrarıdır, yani olay_sirasi ≤ surum. O yüzden WHERE portfoy_gorunum.surum < EXCLUDED.surum bunları doğru atar — bedava, kalıcı ve büyümeyen bir tekrar koruması. Filtrenin kendisi hatalı değildi; hatam onu sırasız teslimatla birlikte kullanmaktı.

Inbox iki durumda hak ediyor yerini. Birincisi, sıra garantin olsa bile karşılaştırabileceğin monoton bir sıra numarası üretemiyorsan — filtrenin bakacağı bir şey yoksa dedup’u başka yerde yapman lazım. İkincisi, olayı işlemek tek satırlık bir delta’dan fazlasını yapıyorsa (bildirim gönder, ikinci tabloya yaz); o zaman “işledim” kaydının satırın içinde değil, tek ve ortak bir yerde durması gerekiyor. Sırasız teslimatta ise inbox seni kurtarmaz: tekrarı engeller, sıra bozulmasını engellemez — delta yine yanlış toplanır.

Inbox’ı seçtiysen temizliğini de planla: tablo sonsuza kadar büyüyor. Günlük bir iş eski satırları siler, ama silme penceresi broker’ın en uzun tekrar teslimat penceresinden uzun olmalı — yoksa çok geç gelen bir tekrar “yeni” görünür ve delta ikinci kez uygulanır. Pratikte 7 gün tutup 3 günlük retention’la çalışmak yeterli oluyor. Sürüm filtresi varsa bu sorunun tamamı yok: surum zaten satırın içinde duruyor ve temizlik istemiyor.

• Yavaşlığın sebebini ölçtüm mü? (Eksik indeks olabilir.)
• Görünüm hangi olaylardan besleniyor, listesi yazılı mı?
• Aynı olay iki kez gelirse iki kez uygulanıyor mu? (Kontrol yorumda mı, ifadenin içinde mi?)
• Inbox’ın anahtarı (tuketici, olay_id) mi? Her görünüm ve her sürümü kendi kaydını tutuyor mu?
• Inbox ne zaman temizleniyor? Pencere, broker’ın tekrar teslimat penceresinden uzun mu?
• Aynı anahtarın olayları sıralı mı geliyor? (Partition anahtarı hesap mı?)
• Sıra numarası nereden geliyor? Partition anahtarıyla aynı anahtarda mı üretiliyor?
• Görünüm hangi olayla besleniyor, ekranda gösterdiği şey o mu? (Pozisyon mu, emir mi?)
• Çift emri engelleyen idempotency anahtarı yazma tarafında var mı?
• Görünüm ne kadar geride kalıyor? Ölçülüyor mu?
• Kullanıcı kendi yazdığını görebiliyor mu?
• Görünümden karar üretiliyor mu? (Üretilmemeli.)
• Görünümü sıfırdan yeniden inşa edebiliyor muyum?
• Yeniden inşa için tam geçmiş mi var, snapshot + sonrası mı? Hangisi, yazılı mı?
• Snapshot hangi olay sırasına karşılık geliyor? Aynı transaction’da mı alındı?
• Snapshot görünümdeki bütün kolonları kapsıyor mu?
• Yeniden inşada canlı akış yeni tabloya da akıyor mu?