wasmCloud ve NATS: Event Bus'ı Taşınabilir Kılmak

Event-driven bir sistemde vendor lock-in runtime’da değil, bus topolojisinde yaşar. Runtime haftalar içinde değiştirilebilir; topoloji çeyrekler alır. Serverless kilitlenmesi tartışmaları bu ayrımı çoğunlukla atlar; Lambda’yı Cloud Functions’a, Workers’ı Containers’a karşı konumlandırır, event bus’ı da tesisat hanesine yazar.

Lambda artı EventBridge event publish etmeyi çok kolay hale getirir, ama bus’ı sahiplenmezsiniz. Routing rule’lar, cross-account izinler, archive ve replay, schema registry, dead-letter akışı, retention semantiği, bunların hepsi AWS şekilli ve hepsi ister istemez sizinle birlikte taşınır. wasmCloud artı NATS bus’ı taşınabilir bir primitife dönüştürür: aynı subject hiyerarşisi, aynı JetStream retention’ı, aynı lattice bugün AWS’te, yarın bir colocation sunucusunda, bir sonraki çeyrekte bir edge point-of-presence’ta event kontratlarını yeniden yazmadan koşabilir.

Lambda ve EventBridge mükemmel araçlar; tamamen AWS’e yaslanmış ekipler için çoğu zaman doğru tercih. Daha dar iddia şu: eğer bus’ın kendisi uzun vadeli mimariniz için önemliyse, bus’ı sahiplenmek runtime’ı sahiplenmekten daha önemli.

Merkezi Bus’a Karşı Federe Lattice

Merkezi yönetilen bus ile federe lattice, koordinasyon yüzeyinin nerede duracağı konusunda farklı bahislere giriyor.

EventBridge ile bus tükettiğiniz bir servistir. Producer bir bus ARN’ine yazar, routing tablosu IAM ve EventBridge rule’ları içinde yaşar, consumer bir Lambda target olur. Event’leri sahibi olmadığınız bir kutuya gönderir ve kutunun bu event’leri kendi dilinde yazdığınız kurallara göre dağıtmasına güvenirsiniz. Cloud değiştirdiğinizde producer kodu bir hafta içinde taşınabilir, bus topolojisi hiç taşınmaz.

NATS lattice üzerinde wasmCloud ile bus çalıştırdığınız bir primitiftir. Producer’lar payments.webhook.received gibi subject’lere publish eder. Consumer’lar load balancing için queue group’larla ya da broadcast için fan-out subscription’larla bağlanır. JetStream stream’ler seçtiğinizi, seçtiğiniz süre boyunca, seçtiğiniz depolamada tutar. Lattice VPC’ler, region’lar, on-prem datacenter’daki leaf node’lar ve gerekirse browser istemcileri arasında kendi kendini kurar, hepsi endpoint yerine subject ile adreslenir.

EventBridge tarafında ortada proprietary kurallara sahip proprietary bir bus var. NATS tarafında ortada bir subject hiyerarşisi var; bu da sadece bir isimlendirme konvansiyonu. Onu taşıyan transport ise sizin kontrol ettiğiniz bir dizi açık kaynak süreç.

Pratik sonuç: yönetilen tarafta bus topolojisi bir AWS artifact’ı ve taşınmak onu yeniden ifade etmek demek. Lattice tarafında bus topolojisi kodla birlikte taşınan bir dizi subject ismi ve stream konfigürasyonu.

Test Yükü Olarak Webhook Fan-Out

Topoloji iddiasını test etmenin en net yolu scheduler’ı değil bus’ı zorlayan bir yük. Webhook fan-out buna uyuyor: tek bir gelen event’in farklı dayanıklılık ve gecikme ihtiyaçlarıyla birkaç consumer’a ulaşması gerekiyor, ki bu tam olarak bir routing katmanının iyi yapması gereken şey.

Denemek istediğim şekil şöyle. Bir wasmCloud HTTP bileşeni ödeme sağlayıcısından gelen bir webhook alıyor. İmzayı doğruluyor, tenant’ı çıkarıyor ve payments.{tenant}.webhook.{event-type} biçiminde bir subject ağacına publish ediyor. Bu ağaca üç tür consumer takılıyor:

1. Bir queue group’a katılan gecikme-hassas bir consumer, böylece mesaj başına tam olarak bir worker entitlement cache’ini günceller.
2. JetStream work-queue stream’i ile desteklenen dayanıklılık-hassas bir consumer, bir gün boyunca düşse bile mesajları kaybetmeden invoicing’i çalıştırır.
3. Interest-based bir stream üzerinde analitik consumer, geç bağlanan aggregator’ların tutulan log’dan backfill yapmasına izin verir.

Dört açık soru:

• Subject tasarımı. payments.{tenant}.* gibi tenant-scoped bir önek yeterli izolasyon veriyor mu, yoksa tenant sayısı arttıkça tenant başına ayrı stream daha iyi mi ölçekleniyor? Retention politikası seçimi (LimitsPolicy, WorkQueuePolicy, InterestPolicy) cevaba bağlı.
• JetStream retention. Invoicing yolu için 7 günlük max-age’li bir WorkQueuePolicy stream doğru şekil mi, yoksa iş aslında replay’li LimitsPolicy mi istiyor? Consumer’ın düştüğü senaryoda bunlar farklı arıza modları.
• Leaf-node şekli. Bir region’ın yerel tüketime ihtiyacı varsa, o region’da filtered JetStream mirror’lı bir leaf node yönetilen tarafla aynı semantiği veriyor mu, yoksa yalnızca yük altında ortaya çıkan zamanlama boşlukları var mı?
• Cross-region lattice. Producer kodu farkına varmadan tek bir mantıksal lattice iki cloud region’ı ve bir on-prem leaf’i kapsayabilir mi? Lattice dokümanları evet diyor; partition altında tutup tutmadığı POC’nin cevaplaması gereken şey.

wasmCloud’un Transport Yol Haritası

İddianın temiz versiyonu “wasmCloud NATS kullandığı için harika” olurdu. Bu çerçeveleme zaten güncelliğini yitirdi. wasmCloud’un Q3 2025 yol haritası scheduler’ı ve provider’ları NATS-varsayılanından aktif olarak ayırıyor ve NATS’ın birkaç seçenekten biri (TCP, WebTransport, Unix Domain Sockets ve QUIC yanına geliyor) haline geldiği transport-pluggable bir wRPC katmanına doğru gidiyor.

Bu değişiklik iddiayı güçlendiriyor. Topoloji iddiasının dayanağı, yönetilen bir router tüketmek yerine routing primitifini sahiplenmek; NATS de bugünkü varsayılan sahiplenme yolu. wRPC transport’u daha da pluggable yaparsa bir wasmCloud lattice’inin koşabileceği yerler kümesi büyür ve lock-in yüzeyi daha da küçülür. Bugün NATS varsayılan ve yukarıdaki keşif onun üzerinden çalışıyor. Yarın aynı actor manifest’i producer kodu fark etmeden belirli bir provider için farklı bir transport pinleyebilir.

Yani doğru okuma dar bir okuma: wasmCloud bugün NATS üzerinden olgun ve yol haritası altındaki transport seçeneklerini genişletmeye devam ediyor.

Bir bağlam daha: wasmCloud’un ticari destekçisi Cosmonic, projeyi 2021’de CNCF’e bağışladı. NATS’ın bakımını ise Synadia üstleniyor; Synadia Nisan 2025’te NATS’ı Business Source License (BUSL) altına alma önerisi getirdi. Yukarıda atıfta bulunulan wasmCloud açıklaması da tam bu öneriye verilmiş bir yanıt. Taşınabilirliği tartarken her iki olgu da önem taşıyor; “bus’ı sahiplenme” argümanı tam olarak bu primitiflerin etrafındaki ticari katmanlar değişebildiği için güçleniyor.

Karşılığında Üstlendiğiniz Operasyonel Yük

Taşınabilir bir bus, vendor sınırını operasyonel sınırla takas eder. EventBridge ile bus’ı AWS çalıştırır: siz onu izlemezsiniz, yamalamazsınız, disk’i dolduğunda uyanmazsınız. Kendiniz çalıştırdığınız bir NATS lattice ile bunların hepsi sizin sorununuz: JetStream depolama boyutlandırması, leaf-node sağlığı, cluster upgrade döngüleri, mesh genelinde TLS rotasyonu.

Sınırı şuraya çekiyorum: zaten stateful altyapı (Postgres, Redis, Kafka) çalıştıran bir ekip için bir NATS cluster eklemek artımsal bir yük ve taşınabilirlik faydası gerçek. Tüm ops duruşu “her şey yönetilen olsun” olan bir ekip için operasyonel sınır bir basamak fonksiyonu artışı; bus’ı daha az sahiplenmek anlamına gelse de EventBridge muhtemelen hâlâ doğru cevap.

Taşınabilir bus argümanı en çok birinci tür ekip için geçerli; mevcut söylemde en az ilgiyi de o ekip görüyor.

Taşınabilir Bus Ne Zaman Değer

Event bus’ınız kısa ömürlü bir üründe küçük bir tesisat parçasıysa EventBridge kullanın ve yola devam edin. Bus topolojisi iki runtime seçimini ve bir cloud vendor’ını geride bırakacaksa taşınabilir yol incelenmeye değer; NATS üzerinde wasmCloud bugün bu yöndeki en olgun yığın ve wRPC yol haritası bu incelemeyi geleceğe daha dayanıklı kılıyor. Sıradaki adım, yukarıdaki subject tasarımı ve leaf-node sorularını test eden küçük bir webhook fan-out POC’si ve sonucunu raporlayan bir takip yazısı.

Kaynaklar

• wasmCloud: NATS ekosistem özeti - Lattice için varsayılan mesajlaşma substrate’i olarak NATS’ın resmi açıklaması.
• wasmCloud: Lattice kavramı - Bileşen ve provider trafiğini taşıyan kendi kendini kuran, kendi kendini iyileştiren mesh.
• wasmCloud: NATS Subjects - RPC ve yaşam döngüsü event’leri için lattice’in kullandığı subject hiyerarşisi.
• wasmCloud: NATS Leaf Nodes - Cross-region ve on-prem lattice uzatımı için leaf-node topolojisi.
• wasmCloud: NATS Server cluster konfigürasyonu - Lattice operatörleri için production clustering rehberi.
• wasmCloud: Lattice protokolleri üzerinde RPC - wRPC’nin bugün NATS transport’u üzerine nasıl oturduğu.
• wasmCloud: Deployment mimarileri - Tek-cluster, çoklu-cluster ve federe lattice’ler için referans topolojiler.
• wasmCloud NATS lisanslama açıklaması - wRPC’nin neden NATS-only bir protokol yerine pluggable bir soyutlama olarak tasarlandığı.
• wasmCloud issue #1542: NATS’ı uyumlu bir sunucu ile değiştir - Q3 2025 yol haritasını besleyen uzun süreli transport pluggability tartışması.
• NATS Docs: JetStream genel bakış - Core NATS üzerine kalıcı streaming katmanı.
• NATS Docs: JetStream streams - Subject-stream bağlaması, retention politikaları ve replay semantiği.
• NATS Docs: JetStream model derin dalış - LimitsPolicy, WorkQueuePolicy ve InterestPolicy retention modlarının detayı.
• NATS Docs: Queue groups - Worker havuzları için kullanılan yük dengeli subscription semantiği.
• AWS: EventBridge event buses - Yönetilen alternatif için event bus kavramları, routing rule’ları ve target seçenekleri.
• AWS: EventBridge rules - Yönetilen routing topolojisini tanımlayan rule ifade yüzeyi.