Bir Üründe Canonical State Nerede Yaşamalı?

“Source of truth” ifadesi o kadar sık kullanılıyor ki bazen hiçbir şey anlatmıyor.

Asıl soru şu:

Bir entity’nin gerçek hâli hakkında iki katman farklı şey söylüyorsa hangisine inanacağız?

Bu sorunun cevabı kodda açık değilse ürün bir noktada yarış koşullarına, silent overwrite’a veya platformlar arası tutarsızlığa girer.

State tek bir şey değildir

Canlı bir üründe aynı bilginin birden fazla temsili olabilir.

Örneğin bir not:

• PostgreSQL’de kayıtlı olabilir,
• TanStack Query cache’inde olabilir,
• optimistic olarak UI’da güncellenmiş olabilir,
• IndexedDB’de recovery için tutulabilir,
• başka cihazda realtime event ile güncellenmiş olabilir.

Bunların hepsi state’tir.

Ama hepsi authority değildir.

Ben rolleri ayırmayı tercih ederim:

Canonical: Son doğrulanmış gerçek. Cache: Hız için geçici temsil. Optimistic: Henüz server tarafından kabul edilmemiş kullanıcı niyeti. Mirror: Canonical kaynağın başka yüzeyde kopyası. Recovery journal: Kaybolmaması gereken fakat henüz kabul edilmemiş değişiklik kaydı. Derived: Başka state’lerden hesaplanan görünüm. Legacy: Artık authority olmaması gereken eski katman.

Problem, bu roller belirsizleştiğinde başlar.

Ordovia’da cloud-authoritative model neden önemli?

Ordovia web, Android ve Windows yüzeylerine sahip yaşayan bir ürün.

Aynı kullanıcı görev, not, ritüel ve planlama verisine birden fazla cihazdan erişebiliyor.

Bu durumda “son açılan cihaz ne biliyorsa gerçek odur” gibi bir model güvenilir değildir.

Ordovia’daki temel karar cloud’u authoritative, client’ları synchronized surface olarak ele almak.

Bu, local state kullanılmayacağı anlamına gelmez.

Tam tersine local cache, optimistic UI ve durable pending mutation deneyimi ciddi biçimde iyileştirebilir.

Ama local katmanların rolü açıktır: canonical gerçeğin yerine geçmezler.

Kurmaca’da recovery neden ikinci source-of-truth olmamalı?

Uzun metin editöründe risk farklıdır.

Yazar sahnede değişiklik yapar. Network gider. Tab kapanır. Cloud revision ilerlemiş olabilir.

Burada local recovery gerekir.

Ama recovery kaydını “en yeni local içerik her zaman doğrudur” şeklinde uygularsanız başka cihazdaki veya cloud’daki daha yeni revision’ı sessizce ezebilirsiniz.

Bu nedenle güvenli model şuna yaklaşır:

Local recovery, kabul edilmemiş authoring intent’i korur. Cloud revision canonical geçmişi temsil eder. Reconciliation iki tarafı revision bilgisiyle karşılaştırır. Conflict varsa sistem sessiz overwrite yerine açık karar üretir.

Bu yalnız teknik doğruluk değil, ürün güvenidir.

Yazar “metnim kaybolur mu?” diye düşünüyorsa editor UX başarısızdır.

Canonical state’i seçmek yetmez

“Supabase source of truth” demek başlangıçtır.

Daha sonra şu yolları da denetlemek gerekir:

• Kim yazıyor?
• Background writer var mı?
• Hydration ne uyguluyor?
• Retry sırasında eski payload yeniden gönderiliyor mu?
• Realtime event optimistic state’i yanlış sırayla mı eziyor?
• Restore logic legacy veriyi geri getiriyor mu?
• Permission layer gerçekten data ownership’i koruyor mu?

Canonical source tek olsa bile canonical’a giden writer’lar kontrolsüzse yine tutarsızlık oluşur.

UI state’i business state’e çevirmemek

Bir başka sık hata: arayüz kolaylığı için tutulan state’in zamanla ürün gerçeği hâline gelmesi.

isArchivedViewOpen selectedFolder expandedCard

Bunlar UI state olabilir.

Ama note.status, task.completedAt, scene.revision business state’tir.

İkisini karıştırırsanız bir component’in mount/unmount davranışı domain gerçeğini etkileyebilir.

Bu özellikle mobil lifecycle ve route transition’larda beklenmedik problemlere yol açar.

Canonical kararını nasıl veriyorum?

Şu sorular yardımcı oluyor:

1. Bu state kullanıcı için kalıcı mı? 2. Birden fazla cihaz tarafından değiştirilecek mi? 3. Conflict ihtimali var mı? 4. Offline değişiklik destekleniyor mu? 5. Hangi katman audit edilebilir? 6. Hangi veri permission/ownership kuralına tabi? 7. Recovery ile authority aynı şey mi? 8. State’in silinmesi veya geri gelmesi kritik mi?

Cevaplar data modelinin nereye oturacağını belirler.

Sonuç

State mimarisi “Redux mu Zustand mı?” sorusu değildir.

Asıl soru:

Hangi gerçeklik ne kadar süreyle, hangi yetkiyle ve hangi amaçla tutuluyor?

Cache’i authority yaparsanız hız kazanırken güven kaybedebilirsiniz. Recovery’yi authority yaparsanız veri korumaya çalışırken overwrite üretebilirsiniz. Optimistic state’i gerçek sanarsanız başarısız mutation’ı başarı gibi gösterebilirsiniz.

State katmanları çoğalabilir.

Authority çoğalmamalı.