Fly.io kesintisi giderildi

 (status.flyio.net)
1 puan yazan GN⁺ 2024-11-27 | 1 yorum | WhatsApp'ta paylaş
  • Fly.io durum sayfası şu anda All Systems Operational durumunda; uygulama çalıştırma, dashboard, Machines API, bölgesel erişilebilirlik gibi başlıca bileşenler çalışır durumda
  • 1 Tem 2026 tarihli Elevated API Errors, GraphQL API hataları ve arka plan işleme sorunları düzeltildikten sonra 07:50 UTC’de giderildi
  • 30 Haz tarihli Delayed Metrics, bazı müşterilerin fly-metrics.net dashboard’unda geciken veya eksik metriklere yol açtı; backlog işlendi ve kapasite artırıldıktan sonra normale döndü
  • Bu durum sayfası küresel kesinti güncellemeleri içindir; sınırlı etkili donanım arızalarını veya izole altyapı olaylarını içermez
  • Uygulama bazındaki etkiler Fly Organization dashboard’undaki personalized status page üzerinden kontrol edilmeli; iç incident’ler ve aktiviteler için Infra Log’a bakılması önerilir

Mevcut hizmet durumu

  • Fly.io durum sayfası şu anda All Systems Operational durumunda
  • Çalışır durumda gösterilen başlıca öğeler Customer Applications, Dashboard, Machines API, Regional Availability, Persistent Storage (Volumes), Deployments, Remote Builds, Logs, Metrics, SSL/TLS Certificate Provisioning, UDP Anycast, Fly Machine Image Registry 1·2, Extensions, Upstash for Redis, DNS, Billing, Managed Postgres
  • Bölge durumu da çalışır durumda gösteriliyor; kapsanan bölgeler AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD, YYZ

Durum sayfasının kapsamı

  • Bu sayfa global incidents güncellemeleri içindir
  • Sınırlı etkili günlük donanım arızaları veya izole altyapı olaylarına ilişkin güncellemeleri içermez
  • Uygulamanızı etkileyebilecek tüm olayların kişiselleştirilmiş görünümü Fly Organization dashboard’undaki personalized status page üzerinden kontrol edilmelidir
  • İç incident’ler ve diğer aktiviteler için Infra Log’a bakılması önerilir

1 Tem 2026: Elevated API Errors

  • Elevated API Errors, 1 Tem 07:50 UTC’de Resolved olarak işaretlendi
  • 06:14 UTC’de GraphQL API ve arka plan işleme süreçlerinde elevated errors için inceleme başlatıldı
  • 06:27 UTC’de neden belirlendi ve düzeltme çalışması başladı
  • 07:05 UTC’de düzeltme uygulandı ve artık elevated API errors görülmemeye başladı
    • Bazı dashboard işlemleri, arka plan işlemleri yetişene kadar gecikebilirdi
  • 07:26 UTC’de arka plan işleri yetişti ve API tamamen çalışır durumdayken izleme sürdürüldü

30 Haz 2026: Delayed Metrics ve SIN/NRT egress IP

  • Delayed Metrics, 30 Haz 22:19 UTC’de çözüldü
  • fly-metrics.net dashboard’undaki müşteri metriklerinde sorun oluştu; kullanıcılar gecikmiş veya eksik metrikler görebilirdi
  • Birden fazla host’taki sorunlar metrik toplamada gecikmeye yol açtı; bazı metrics ingestion hosts üzerindeki resource contention neden olarak ele alındı
  • Backlog’u işlemek için metrics cluster’ın throughput’u artırıldı; ingestion traffic yeniden dengelendi ve ek işleme kapasitesi devreye alındı
  • 30 Haz 19:58 UTC’de metriklerin neredeyse tamamı yetişmişti, ancak sin ve syd için az sayıda metrik kalmıştı
  • Egress IP issues in SIN and NRT, 30 Haz 14:03 UTC’de çözüldü
    • SIN ve NRT’de egress IP kullanan bazı Machines geçici olarak bağlantı kaybı veya performans düşüşü yaşayabilirdi

26~25 Haz 2026: ağ, dağıtım ve control plane olayları

  • IPv6 Connectivity Issues in EWR, 26 Haz 23:48 UTC’de çözüldü
    • upstream provider kaynaklı IPv6 ağ bağlantısı sorunu EWR’de yaşandı
    • Etkilenen host’larda Machines bulunan uygulamalar, belirli IPv6 hedeflerine bağlantıda etkilenebilirdi
  • Network maintenance in YYZ, 26 Haz 08:00~09:00 UTC arasında yapılan planlı bakım çalışmasıydı ve tamamlandı
    • Bakım penceresi içinde en fazla 15 dakikalık bağlantı kaybı bekleniyordu
  • Deploys defaulting to Fly-hosted Builders, 25 Haz 15:38 UTC’de çözüldü
    • Depot backed builders provisioning gecikmesi incelenirken varsayılan fly deploy stratejisi Fly-hosted builders’a geçirildi
    • Kullanıcılar fly deploy --depot=true ile Depot tabanlı dağıtımı zorlayabiliyordu; daha sonra fly deploy --depot=false ile Fly builder tabanlı dağıtım da mümkün oldu
  • Elevated control plane latency, 25 Haz 15:18 UTC’de çözüldü
    • BOM ve NRT bölgelerini etkileyen control plane latency ve saturation yaşandı
    • Bu bölgelerde Machines bulunan uygulamalar daha uzun yanıt süreleri ve olası 502 errors yaşayabilirdi

24~17 Haz 2026: Kuzey Amerika ve SIN/NRT ağı ile log arama

  • Degraded networking in North America, 24 Haz 06:57 UTC’de çözüldü
    • Kuzey Amerika siteleri arasındaki ağ performans düşüşü, upstream incident nedeniyle incelendi
    • Bazı Machines belirli rotalarda paket kaybı ve daha yüksek gecikme görebilirdi
    • LAX bölgesine giden veya bu bölgeden gelen bazı 6PN Private Networking trafiği üzerindeki etki devam ediyordu
  • Network issues in SIN, NRT, 22 Haz 21:56 UTC’de çözüldü
    • upstream provider, SIN ve NRT bölgelerinde ağ sorunları yaşadı; bu bölgelerdeki uygulamalar erişilemezlik veya yüksek paket kaybı yaşayabilirdi
  • SIN, NRT network issues, 22 Haz 19:48 UTC’de çözüldü
    • Başta SIN bölgesinde upstream network issue olarak incelendi; daha sonra NRT bölgesindeki uygulamalar da belirli hedeflere erişim sorunu yaşayabilirdi
  • Log search unavailable, 19 Haz 21:53 UTC’de çözüldü
    • Fly Metrics log search panellerini ve fly logs komutunda ilk dönen historical application logs kayıtlarını etkiledi
    • fly logs streaming, dashboard’daki Live Logs sayfası ve Fly Log Shipper services normal çalıştı
    • Düzeltmeden sonra historical logs backfill edildi ve kuyruğa alınmış historical logs kayıtlarının çoğu aranabilir hale geldi
  • Network Issues in SIN, 17 Haz 04:55 UTC’de çözüldü
    • SIN bölgesinde ağ bağlantısı sorunu vardı ve hosted apps kullanılamaz durumda olabilirdi
    • Bazı Machines erişilemez durumdaydı; bazı Managed Postgres clusters fail-over veya update işlemlerinde başarısız olabilirdi

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-27
Hacker News yorumları

  • fly.io üzerinde barındırdığım web sitem yaklaşık 6 saat önce 5 dakikalığına çöktü, hemen ardından toparlandı ve o zamandan beri sorunsuz çalışıyor
    Ücretsiz izleme servisi 5 dakikada bir kontrol ettiği için daha kısa kesintileri kaçırmış olabilir; ama genel olarak oldukça stabildi

    • Birkaç aylık veriye bakmak ilginç olurdu
      Uygulamanın çalışma süresi de istikrarsız, ama daha kötüsü fly deploy hatalarının sebepsiz yere ortaya çıkmasıydı. Bazen bir katman öylece takılı kalıp sonunda başarısız oluyordu; 1-2 saat sonra hiçbir değişiklik yapmadan aynı komutu yeniden çalıştırınca düzgün çalışıyordu
      Temel bir uygulamayı 5 dakikada bir dağıtan bir izleme servisi, yani fly deploy komutunu periyodik olarak çalıştırıp dağıtımların ne sıklıkla başarısız olduğunu veya takıldığını görmek isterdim. Tahminen yaklaşık %5’i açıklamasız başarısız olur gibi geliyor; vaktiniz bol değilse epey sinir bozucu bir seviye
    • fly.io’yu ve dokümantasyonunu dışarıdan izliyorum: https://flyio.onlineornot.com/
      Bu tarafa göre 16 dakika sürmüş gibi görünüyor
    • Bizde de benzer şekilde yaklaşık 5 dakika çöktü, sonra toparlandı ve ardından sorun olmadı; hata 501 idi

  • fly.io olay sonrası analizini burada yayımladı: https://fly.io/infra-log/
    Son olay sonrası analizleri oldukça ilginç ve ayrıntı bakımından zengin. 2016’da fly.io’nun operasyon altyapısının temel bileşeni, consul adlı yüksek güvenlikli bir TLS sunucusuydu; paylaşılan durumu izlerken hem sunucu sertifikalarını hem de istemci sertifikalarını doğrulaması gerekiyordu
    Merkezi bir yapı olduğu için ölçeklenebilirlik sorunları doğdu; fly.io 2020’de bunun yerine corrosion’ı geliştirdi ve consul’u hızla unuttu, ama tamamen kaldıramadı
    Derken Ekim 2024’te consul’un kök anahtar imzalama anahtarının süresi dolunca tüm bağlantılar düştü; karşılıklı kimlik doğrulama kullandıkları için tüm makinelere yeni SSL sertifikaları dağıtılana kadar sistemi toparlamak mümkün olmadı. Bir şekilde bunu 30 dakikada başardılar, ama domino etkisi çoktan başlamıştı ve altyapıdaki başka zayıf noktalar da ortaya çıktı
    Bir başka dahili servisin bağımsız TLS anahtar setinin süresi çoktan dolmuştu; ancak consul anahtarlarını yeniden yayımlama sürecinde servis yeniden başlatılana kadar bunu fark etmemişlerdi. Sertifikalar hâlâ geçerliyken kurulmuş TCP bağlantıları yeniden başlatmayla kopunca mesele açığa çıktı. Bu sırada loglama aracı da ağ sağlayıcısına DDoS yapıyormuş gibi yükleniyordu. Bu kadar çok şey aynı anda patladığında şirketi ayakta tutup müşterileri de koruyan insanlar gerçekten etkileyici

    • Fly Infra, o Consul kesintisi hakkında “çıkarılan ders, artık yarım yamalak önlem olmayacağıdır” sonucuna varmıştı
      Ama işe alım sayfasında [1] “teknik borca pek inanmıyoruz” diyorlar
      Dışarıdan bakınca çelişkiler korosu gibi okunuyor
      [1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...

  • Fly.io oldukça iki yüzlü bir hizmet gibi görünüyor
    https://news.ycombinator.com/item?id=41917436
    https://news.ycombinator.com/item?id=35044516
    https://news.ycombinator.com/item?id=34742946
    https://news.ycombinator.com/item?id=34229751
    Bir bulut platformu güvenilirliği düzgün şekilde sağlayamıyorsa buna değmez diye düşünüyorum. Sadece sanal sunucu kiralayıp bulut vergisinden tasarruf etmek daha iyi olabilir

    • Deneyler veya hobi projeleri için değer önerisi harika. Ayda $1.94 karşılığında bağımsız bir instance çalıştırabileceğiniz başka neresi var ki?
      Ancak bu fiyat 256 MB RAM’li instance için geçerli (https://fly.io/docs/about/pricing/). Yine de bunun üzerinde anlamlı projeler çalıştırmak gayet mümkün. Rocket gibi Rust tabanlı web sunucuları yalnızca yaklaşık 10 MB RAM istiyor; araştırdığım kadarıyla temel PHP sunucusu da sığabiliyor
    • Güvenilirlik gerçekten çok kötü. Son birkaç ay içinde demo yaparken ana dashboard’un iki kez çökmüş olması kabul edilemezdi
      Dağıtım sorunları bir yana, neredeyse her gün bir şeyler rastgele çalışmıyor ya da gecikiyordu
      Fiyat artışı ve patronumun Fly’a koyduğum projede birkaç kez sorun görmesi yüzünden birkaç ay önce ayrılmak zorunda kaldım
      Üstelik sqlite yedekleme hizmetini de kullanımdan kaldırıp kaldırdılar. Şimdi GCP’ye döndüm ve sayısız arıza konusunda endişelenmiyorum
    • fly.io’nun değer önerisini pek anlayamıyorum. Arızalar olsa da mühendislik ekibi etkileyici, ama edge computing geliştiricilerin %99,9’u için gerçekten gerekli mi?
      Tek bir AWS bölgesinde çalışıp dünyanın dört yanından milyonlarca kişinin kullandığı çok sayıda büyük şirket hizmeti var. Varsayılanlardan itibaren erken optimizasyonu mümkün kılan bir şey gibi hissettiriyor
    • Bu bakış açısı tamamen makul ve özellikle itiraz etmeyeceğim. Çok zor bir şey inşa ediyoruz, görece yeni bir şirketiz ve hyperscaler’ların sahip olduğu kaynakların çok küçük bir kısmına bile sahip değiliz. AWS, GCP, OCI’nin başladığı dönemle karşılaştırınca bile böyle
      Güvenilirliği maksimize etmeyi hedefleyerek optimizasyon yapıyorsanız, bu da tamamen makul bir tercih. 2024’te UE1’de daha iyi olduğumuzu söylemeyeceğim
      Referans olması açısından: pek çok şey ters gidebilir ve gerçekten de gidiyor, ancak burada en sık görmeniz muhtemel arıza biçimi dağıtım yapılamayan dönemler. Bu arıza dağıtım/orkestrasyon arızasıydı. Birkaç ay önce Rust eşzamanlılık mayınına basıp tüm istek yönlendirmesinde arıza yaşamıştık, ama bu tür şeyler çok nadirdir
      Dağıtım ve durum güncelleme arızaları da büyük mesele; bizim önerdiğimiz gibi çeşitli Fly Machines gruplarına sürekli dağıtım yapıyorsanız, platformun büyük özelliklerinden biri olduğu için erişilebilirliği etkileyebilir. Bunu küçümsemeye çalışmıyorum
    • fly.io’nun güvenilirlik konusunda itibarı çok kötü ve Hacker News dışında pek bir imaj toparlaması da görünmüyor. Burada bile uzlaşı “kritik işleri fly.io’da çalıştırmayın ve veri yedekliliği de beklemeyin” noktasına yakın görünüyor
      Aslında kendi bare-metal sunucularınızda Firecracker çalıştırırsanız fly.io’nun yaptığının neredeyse aynısını daha ucuza da yapabilirsiniz
      fly.io’ya dair kamu algısı artık toparlanması zor olacak kadar lekelenmiş gibi. Artık kaç kez özür dilediklerini sayamıyorum bile

  • Yazı başlığının aksine Fly.io API hâlâ erişilemez durumda. Bu, kullanıcıların hâlâ dağıtımlara, veritabanlarına vb. erişemediği anlamına geliyor
    Doğru güncellemeler için https://community.fly.io/t/fly-io-site-is-currently-inaccess... adresine bakılabilir

  • Hem Fly.io hem Railway.com kullanmış kişisel deneyimime göre Railway açık ara üstün. Railway desteği de kıyaslayınca harika
    Fly.io, destek e-postasına gönderdiğim veri silme soruma bugüne kadar yanıt vermedi
    Railway uygulaması şimdiye kadar büyük bir kesinti olmadan çevrimiçi kaldı. İyi bir alternatif arayanlara Railway’i denemelerini öneririm

    • Railway kontrol panelini hayatım boyunca toplam yaklaşık 10 kez kullandım; yarısında garip sorunlar vardı. Kontrol paneli arayüzü yüklenmiyor ya da çalışmıyor, işlemler başarısız oluyor, dağıtımlar rastgele başarısız oluyordu
      Fikir güzel ama pratikte ciddi kullanım için tercih etmek istemem
    • Fly kendi donanımı üzerine kurulmuş. Railway de aynı şekilde mi? Değilse, Railway’de görece daha az arıza olmasının bir kısmı açıklanır. Çünkü mühendislik yapılması gereken şey daha azdır
      Son kullanıcıların güvenilirlik istediğini anlıyorum ve Fly’ın son 2 yılda buna epey yatırım yapmasına rağmen itibarının kötü olduğunu da biliyorum. Ama bu tür arızalar bir sağlayıcıda olup diğerinde olmayan türden şeyler değil. Bulut altyapısı kurmak hiç kimse için kolay değil

  • Bizzat gördüğüm kadarıyla bile Fly.io’nun büyük arızaları muhtemelen 5. ya da 6. kez oluyor. Başka arızalar da çoktu ve bazılarını görmeden geçmiş olmam çok olası
    Bu hizmeti bir arkadaşıma önermiştim; iki gün içinde iki kez arıza yaşadı
    Fly.io’nun gerçekten kendine çeki düzen vermesi gerekiyor. Neden hâlâ bunu başaramadığı muamma. Ürün iyi ama bir hosting hizmetiyseniz kararlılık mutlak birinci öncelik olmalı. Geri kalan her şey ikincil

    • Anlıyorum ama insanlar GitHub’ın iki haftada bir büyük şekilde patlamasını tolere ediyorsa Fly’a da bir miktar iyi niyet gösterilebilir diye düşünüyorum. Fly ile hiç ilgim yok, ama dev şirketler bile bunu düzgün yapamıyorsa beklentileri düşürmek gerekiyor
      Sır, alternatifi pek olmayan yerleşik güçlü oyuncu olmak gibi görünüyor. O zaman güvenilirlik açısından tamamen berbat olsanız bile herkes operasyonel başarısızlıkları kabaca geçiştiriyor
    • Yaklaşık 1 yıl önce güvenilirlik sorunları nedeniyle ayrıldım. Şimdi DigitalOcean Apps kullanıyorum ve çok iyi çalışıyor. DO’da kesinti 0 oldu
    • Trafik ölçeği üstel olarak büyüyorsa güvenilirliği korumak zordur
    • Ücretsiz katmanın ötesinde gerçekten kullanan var mı? Vercel için de aynı şey geçerli

  • Şüpheli biçimde, Turso da neredeyse aynı anda sorun yaşamaya başlamış. CEO, Discord’da bunun Fly kesintisinden kaynaklandığını doğrulamış

    Ok.I caught up with our oncall and This seems related to the Fly.io incident that is reported in our status page. Our login does call things in the Fly.io API
    we are already in touch with Fly and will see if we can speed this up

    • Turso’nun Fly sorunu yüzünden devre dışı kalması ilk kez olmuyor. Bir veritabanı servisi kurup böyle bir kesinti yaşamak gerçekten can yakıcı olmalı
      Görünüşe göre Turso bir noktada AWS katmanı sunacak

  • Şaşırtıcı değil. Yaklaşık 1 yıl önce düşük fiyatları nedeniyle fly.io’ya bakmıştım ve nereden maliyet kısıp para kazandıklarını merak etmiştim. Sonunda cevabı teknik dokümanlarda buldum: fly instance’ının tek bir fiziksel sunucuya sabitlendiği ve o sunucu ölürse failover yapılamayacağı açıkça yazıyordu. Bu kısmın hâlâ resmi dokümanlarda olup olmadığını bilmiyorum
    Pratikte bunun anlamı şu: sunucu düşerse ilgili instance’ın son snapshot’ını yedekten alıp yeni bir sunucuya koymanız, ağ yolunu güncellemeniz ve boş kapasiteden daha fazla sunucunun ölmemesi için dua etmeniz gerekiyor. Aksi halde veri merkezinin rack’e birkaç sunucu daha takmasını beklemek zorundasınız
    Bu yüzden kesinti raporlarının rastgele görünmesi de epey açıklanıyor. Bazı uygulamalar düşüyor, bazıları sorunsuz kalıyor; bazıları 5 dakikada geri geliyor, bazıları uzun sürüyor
    Bütçesi sıkı bir iş için küçük bir civo cluster’ı gibi başka seçenekler daha iyi olabilir

    • Fly.io artık VM’leri ve volume’ları migrate edebiliyor: https://fly.io/docs/reference/machine-migration/ / https://archive.md/rAK0V
      “fly instance’ı tek bir fiziksel sunucuya sabitlenmiş ve failover yapılamıyor” kısmında, bunun başka nasıl olması gerektiğini pek anlamıyorum. Canlı migration olduğunu biliyorum ama o durumda bile VM sonuçta bir fiziksel sunucuya “sabitlenmiş” olmuyor mu?
    • EC2 instance türlerinin büyük çoğunluğunda da çok yakın zamana kadar canlı migration yoktu. Bazılarında hâlâ olmaması oldukça muhtemel. Ne zaman ve nasıl çalıştığını da açıkça yazmıyorlar
      Üstelik ücretsiz de değil. Örneğin GCP’de bir VM migrate edildiğinde hissedilebilir geçici performans düşüşü oluyor
    • Fly’da yüksek erişilebilirlik istiyorsanız uygulamayı birden fazla region’a, yani birden fazla makineye dağıtmanız gerekir
      Proxy katmanı arızalanırsa Fly’ın tamamı yine düşebilir ama bu tür durumlar çok daha az yaygındır
    • Durum sayfasına bakınca bu bir yüksek erişilebilirlik/clustering sistemi arızası gibi görünüyor. Bu kez, yüksek erişilebilirlik donanımının karmaşıklığının sistem erişilebilirliğine basit bir VPS benzeri kurulumdan daha fazla zarar verdiği bir duruma daha yakın gibi

  • Tekrarlayan kalıp, ABD’de büyük tatillerin olduğu haftalarda kesintilerin sık yaşanması
    MS 365/Teams/Exchange de sabah kısa süreli sorun yaşadı, Fly.io tamamen kesildi ve ardından çeşitli siteler ve servisler bunun etkisiyle sarsıldı
    Normalde “değişiklik dondurma”ya karşıyım, ama büyük tatillerin öncesi ve sonrasında değişiklik dondurma mantıklı geliyor. Tüm ekiplere yeniden enerji toplama, ara verme ve bakım zamanı sağlayabilir
    Nöbeti üstlenen B ekibine gereğinden fazla baskı bindirmemek daha iyi

    • Bu ölçekteki kesintilerde neden nadiren kötü koddur. Suçlu neredeyse her zaman konfigürasyon değişikliğidir
      Tatil döneminde bu tür değişiklikleri de azaltmaya çalışabilirsiniz ama sertifika yenilemek gerekirse? Önemli bir güvenlik yaması uygulamak gerekirse? Bir sunucu grubunu yeniden provision etmek gerekirse? Disk alanı tükenirse?
      Yılın hangi zamanı olursa olsun, operasyonel zorlukları yalnızca planlama ile önleyemezsiniz
    • Bu tür tatil haftalarının normalden farklı olduğu gerçeğinden kaçamazsınız. “Değişiklik dondurma” koyduğunuzda, genelde sistem genelinde yapılan küçük düzeltmeler ve performans tuning’leri de “önemli değil” diye engellenir
      Sonra eninde sonunda özel bir pazarlama/ürün atağı çıkar; özel fiyatlandırma mantığı yeni kod ve yeni UI widget’ları gerektirir, trafik ve yük ciddi şekilde sıçrar ve dondurma varken bile hemen yayına çıkması gerekir. Gelirle ilgili olduğu için yönetim açısından önemlidir
      Çoğu mühendislik ve altyapı ekibinin bundan haberi yoktur; çünkü ürün ekibi işi son ana kadar zorlamış ve bir ölçüde gizli yürütmüştür. Sonuçta kaliteli küçük düzeltmeleri dondurabilirsiniz ama istikrarsız yeni özellikleri düzgün biçimde donduramazsınız
      Zor bir iş; yine de dondurmayı unutup öncesinde, sonrasında ve sırasında aşırıya kaçmayan makul operasyonu öneririm
    • Kısa süreli sorun mu? 365’te Avrupa saatiyle dün sabahtan beri devam eden bir kesinti var. Büyük bir iflas dosyasında bilgileri korumak için uyumluluk araçları kullandığımızdan öğrendim
    • O zaman geliştiriciler değişiklikleri dondurmadan önce aceleyle içeri sokmaya çalışır sadece
    • “Dondurma” tam olarak ne anlama geliyor? Sertifika yenilemeyi mi durduruyorsunuz? Yazılım güvenlik güncellemelerini almıyor musunuz?
      “Gereksiz” değişiklikleri engelleyebilirsiniz ama sınır çok hızlı gri alana dönüşür

  • 2023 başındaki ardışık kesintilerde de Corrosion ile ilgili sancılar vardı: https://community.fly.io/t/reliability-its-not-great/11253

    • Kendi veri deposunu yapma tercihi kötü bir bahis olmuş gibi
      Kısıtları çok iyi bilmiyorum ama ScyllaDB nihai tutarlılığı destekliyor ve genel olarak oldukça esnek. Çoklu lider replikasyonu için CouchDB de bir seçenek