EventSourcingDB 1.3.0 daha hızlı yazma, sınırlı istekler ve yeni sonuç raporlama v2 API'si sunuyor

EventSourcingDB 1.3.0 yayınlandı

EventSourcingDB 1.3.0, 11 Kasım 2026'da duyuruldu ve projenin blogundaki yazıya göre yeni sürüm, daha önceki tüm sürümlerden daha hızlı ve daha kararlı. Yazma işlemleri ve EventQL sorguları en büyük hız kazanımını elde etti, okumalar da iyileşti ve sürüm altımdan fazla düzeltmeyi içeriyor. Duyuruya göre yazma işlemleri artık depo büyüdükçe yavaşlamıyor ve disk üzerindeki indeksler çok daha az dosyaya ihtiyaç duyuyor; bu da büyük veritabanlarında bir subject'in event'lerini okumayı hızlandırıyor. Aynı sürüm, kabul edilen her isteğin sonucunu response body içinde raporlayan bir v2 HTTP API'si tanıtıyor ve dokümantasyon artık eventfoundation.io üzerinde yaşıyor.

Sıkı sınırlarla kararlılık

1.3.0'daki mühendisliğin büyük kısmı savunmaya yönelik. Artık her istek, response ve boşta bekleyen bağlantı bir zaman sınırı taşıyor; böylece yavaş veya takılmış bir istemci kaynakları süresiz olarak işgal edemiyor. EventQL sorgularında iç içe derinlik ve bellek kullanımı için sınırlar var; bu da tek bir sorgunun stack'i taşırmasını veya sınırsız bellek tüketmesini önlüyor. Bütünlük kontrolleri artık buldukları her tutarsızlığı, ilkinde durmak yerine, yüze kadar listeliyor.

Hata yönetimi de daha açık. Bir yazma işlemi depolanamıyorsa — örneğin disk doluysa — sunucu read-only moduna geçiyor, okumaları sunmaya devam ediyor, durumu health endpoint'inde görünüyor kılıyor ve nedeni log'luyor. API token'ları sabit zamanda karşılaştırılıyor ve sunucu, tahmin edilebilecek kadar zayıf bir token ile başlamayı reddediyor.

v2 API sonuçları body içine koyuyor

v2 API, aynı veri üzerinde v1 ile birlikte çalışıyor. Organize edici ilkesi şu: bir istek kabul edildiğinde — kimliği doğrulandı, doğru biçimde ve sınırlar içinde — sonucu body içinde gelir. Başarısız bir ön koşul, bilinmeyen bir event türü veya read-only bir veritabanı, istemcinin çözmesi gereken status code'lar yerine makine tarafından okunabilir yanıtlar olarak döner ve her hata, nedeni ve çözümü açıklayan bir dokümantasyon sayfasına karşılık gelen bir kod taşır.

Event okumaları gibi stream edilen yanıtlar açık bir bitiş işaretiyle kapanıyor; böylece istemciler tamamlanmış bir stream ile kopmuş olanı ayırt edebiliyor ve sunucu, bir stream beklerken proxy'lerin bağlantıyı kapatmaması için heartbeat gönderiyor. Ön koşullar da recursion kazandı: isSubjectPristine, isSubjectPopulated ve isSubjectOnEventId artık bir subject'e, altındaki her şeyle birlikte uygulanabiliyor; bu da bir kararın tüm bir alt ağaca bağlı olduğu durumlarda önemli.

Sekiz istemci SDK'sının tümü her iki API'yi konuşuyor ve sunucunun sunduğu yerde varsayılan olarak v2'yi kullanıyor; böylece çoğu uygulama için yalnızca bir SDK güncellemesi yeterli — tabii veritabanının önündeki her proxy, yeni API'nin okumalar için kullandığı HTTP QUERY metodunu geçiyorsa. v1, 31 Ocak 2027'ye kadar desteklenmeye devam edecek.

Veri taşıma ve üretim varsayılanları

Export ve import, satır başına ID ve timestamp dahil düz bir CloudEvent kullanıyor; böylece bir export, dönüştürme olmadan yeniden import edilebiliyor. Import edici hash'leri kendisi hesapladığı için operatörler, hash'leri elle yeniden hesaplamadan bir geçmişi export edip kişisel verileri temizleyip yeniden import edebiliyor — bu, gizlilik odaklı redaction için sessiz ama yararlı bir özellik. Artımlı yedekler yalnızca önceki yedekten sonra yazılan event'leri yakalıyor ve event'ler toplu halde yazıldığı için geri yüklemeler daha hızlı.

Operasyon tarafında, rate limiting varsayılan olarak açık ve makineyle ölçekleniyor, v2 health endpoint'i doğrudan Prometheus scraping'i için OpenMetrics konuşuyor ve bellek ve file descriptor gibi süreç ayrıntılarını raporluyor ve kayıtlı şeması olmayan event türlerinin yazılmasını reddeden yeni bir --require-event-schemas flag'i (varsayılan olarak kapalı) bulunuyor. /.well-known/api-catalog adresindeki bir API kataloğu, araçları her iki API'nin OpenAPI dokümanlarına yönlendiriyor.

Yükseltme gerçek riskler taşıyor

Duyuru, bu yükseltmenin hazırlık gerektirdiğini açıkça söylüyor. 1.3 tarafından açılan bir veri dizini daha eski bir sürüm tarafından yeniden açılamıyor; bu nedenle geri dönüşün tek yolu bir yedek. Eski sunucu önce durdurulmalı: 1.2'ye kadar olan sürümler veri dizinini kilitlemiyor, dolayısıyla bir Kubernetes rolling update aynı veri üzerinde iki sunucu çalıştırıp ona zarar verebilir. Docker image'ı UID 100'den 65532'ye geçiyor ve bu, tek seferlik bir sahiplik aktarımı gerektiriyor. 1.3, event hash'inin yeni bir sürümünü yazdığı için hash doğrulayan uygulamalar önce SDK'larını güncellemeli, yoksa yükseltme sonrası her event üzerinde değiştirilmiş gibi görünecek. --ai-model ve --ai-option flag'leri kaldırıldı ve başlatmayı engelleyecekler; API token'ları artık en az 32 yazdırılabilir ASCII karakter olmalı, EventQL karşılaştırma semantiği değişti (event ID'leri string, tarih ve saatler UTC) ve ilk açılış, EventQL sorgularını birkaç dakika sürebilecek bir süre boyunca reddederek indeksleri yeniden oluşturuyor.

Neden önemli

v2 API'nin temel tasarımı — body içindeki sonuçlar, adlandırılmış hata kodları, açık stream sonlandırıcıları, heartbeat'ler — status code'ların domain anlamını belirsiz taşıdığı HTTP API'lerinin kronik bir zayıflığına saldırıyor ve diğer API tasarımcılarının kopyalaması muhtemel bir pattern. Zamanla sınırlı isteklerden zarif read-only bozulmaya ve varsayılan rate limiting'e uzanan operasyonel sağlamlaştırma, üretim seviyesindeki veritabanlarını demo'lardan ayıran gösterişsiz iş. Aynı zamanda, geri döndürülemez veri formatı ve yeni event hash, projenin kullanıcı tabanı hâlâ küçükken uyumluluğu şimdi kırma, ödünleri süresiz taşımama isteğini gösteriyor — ve Ocak 2027 v1 son tarihi operatörlere sağlam ama cömert bir geçiş saati veriyor. Event-sourcing altyapısını değerlendiren ekipler için redaction dostu export ve import döngüsü bu sürümün gizli kalmış özelliği olabilir.