Solid Objects, Cloudflare'ın Durable Objects modelini Postgres, SQLite ve MySQL'e taşıyor

Nedir

Solid Objects adlı yeni bir açık kaynak kütüphane, Cloudflare'ın Durable Objects programlama modelini — kalıcı state'e sahip, uzun ömürlü, tek iş parçacıklı (single-threaded) actor'leri — sıradan ilişkisel veritabanlarına getiriyor. Projenin sitesinde yayımlanan ve Hacker News ana sayfasına çıkan tanıtım yazısına göre her object bir kimliğe, kalıcı state'e ve sıralı bir mailbox'a sahip; ve tümü uygulamanın halihazırda kullandığı SQLite, PostgreSQL veya MySQL veritabanında yaşıyor. Ayrı bir daemon dağıtmanız, message broker veya platform hesabı gerekmiyor. Kütüphane Node 24+ için bir npm paketi ve Rails 7.1+ için bir gem olarak geliyor; tablolarını Rails'in Solid Queue ve Solid Cache'i gibi mevcut veritabanına kuruyor.

Satıcı olmadan model

Yazıya göre Durable Objects deseni — tek bir kimliğin aynı anda tek bir çağrıyı işlemesi ve request'ten daha uzun yaşayan state — şimdiye kadar ödünlerle birlikte geldi. Cloudflare'da bu modeli benimsemek, state'i ve faturalandırmayı tek bir satıcıya bağlamak anlamına geliyor. Yazı, ölçümlü fiyatlandırmanın öngörülmesinin zor olduğunu savunarak, kullanıcısı olmayan bir lansman öncesi geliştiricinin kontrolden çıkan bir alarm döngüsü yüzünden sekiz günde iddiaya göre 34.000 dolar fatura ödediği bir vakaya dikkat çekiyor. Celld gibi self-hosted alternatifler ise satıcıyı, her düğümde bir süreç ve replikasyon için bir bucket ile takas ediyor ve yedeklenip izlenmesi gereken bir state'li sistem daha ekliyor. Solid Objects bunun yerine uygulama veritabanını doğruluk kaynağı (source of truth) olarak ele alıyor.

Bir turn nasıl işler

Her çağrı, object'in kimliğine göre anahtarlanan sıralı bir mailbox'a girer. Fenced bir lease, turn'ü hangi sürecin çalıştıracağını belirler; state değişiklikleri, zamanlanmış hatırlatıcılar, giden etkiler (bir outbox'a yazılır) ve broadcast'ler tek bir veritabanı transaction'ında commit edilir. Lease'ini kaybetmiş bir worker commit edemez. Redis isteğe bağlıdır ve yalnızca uyanma gecikmesini kısaltır; PostgreSQL bildirim kanalları süreçler arası uyanmalar için benzer bir amaca hizmet eder.

Neğin yerine geçiyor

Yazar, bu desenin yerini aldığı el yapımı yığını şöyle anlatıyor: önce bir satır kilidi (row lock), kilit iki request'e yayılması gerektiğinde bir Redis kilidi, bir expiry kolonu, bir delayed job, süreçle birlikte ölenleri kurtarmak için bir sweeper cron, retry kodu ve yazmaları takip ettiği verilerle çelişebilen broadcast'ler — koordineli altı parça tek bir object'te birleşiyor. Yazı, beş dakikalık cron'unun tüm aktif hesapları taradığı bir uygulamadan söz ediyor: bir haftada 2.014 çalıştırma ve 37 dakikalık queue süresi yalnızca sekiz hesap buldu. Yazar ayrıca Shopify'ın bağımsız olarak temelde aynı mimariyi yayımladığına dikkat çekiyor — envanter rezervasyonları Redis'ten MySQL'e taşındı, birim başına bir satır, SKIP LOCKED ile claim ediliyor — ve yazı bunu, sorunun yeni keşfedilmiş değil güncel olduğunun kanıtı olarak okuyor.

Benchmark'lar ve uyarılar

SQLite kullanan bir geliştirici dizüstü bilgisayarında, tek süreç içinde bir kalıcı çağrının enqueue'dan commit edilmiş tamamlanmaya kadar medyan süresi yaklaşık 2,6 ms ölçülmüş. Yalnızca polling'e dayanan iki süreç arasında ise bekleme kabaca bir saniyeye uzuyor; PostgreSQL bildirimleri ve isteğe bağlı Redis uyanması bu yüzden var. Proje benchmark araçlarını ve uyarılarını yayımlıyor ve dizüstü ölçümlerinin uygulama kapasitesini öngörmediği konusunda uyarıyor.

Sınırlamalar açıkça belirtilmiş: edge yerleşimi veya bölgeler arası yönlendirme yok, iki kimliği kapsayan transaction yok ve exactly-once yerine sıralı, en az bir kez teslim var — dolayısıyla dış etkiler idempotent olmalı. Proje 1.0 öncesi aşamada, 100.000'den fazla kullanıcısı olan tek bir uygulamada production'da çalışıyor ve henüz üçüncü taraf production kullanımı yok. Shuffleupandplay.com adresinde herkese açık bir demo mevcut. Tamamen tek bir request'in içine sığan mantık için, yazının tavsiyesine göre, düz bir transaction hâlâ doğru araç. Yol haritasında sıradakiler: tekrarlanabilir benchmark'lar, PostgreSQL ve MySQL üzerinde daha fazla soak süresi ve ardından 1.0 sürümü.

Neden önemli

Durable Objects, kendi state'ine sahip tek bir serialize edilmiş actor'ün koordinasyon sorunlarını — rezervasyonlar, geri sayımlar, bilet sayaçları — çözmek için verimli bir yol olduğunu kanıtladı; ama bunu benimsemek tek bir satıcının runtime'ına ve ölçümlü faturalandırmasına angaje olmak anlamına geliyordu. Solid Objects modeli taşınabilir kılıyor: Postgres veya MySQL çalıştıran herhangi bir ekip, sıralı, transaction'lı actor'leri bir kütüphane olarak edinebilir ve state, sorgulayabilecekleri, yedekleyebilecekleri ve kendilerinin migrate edebileceği tablolarda yaşar. Shopify'daki paralel hamle, bu desenin talebinin Cloudflare platformunun çok ötesine uzandığını gösteriyor. Uyarılar gerçek — en az bir kez teslim, çoklu object transaction'larının yokluğu ve genç bir kod tabanı — ama kilitlenmeyi tartan ekipler için hesap değişiyor: Durable Objects'i benimsemeye değer kılan kısım, çıkış yolunda yeniden yazılmak zorunda değil.