Inngest kesintisi: yeniden başlatılan servisler, kesintinin devre dışı bıraktığı veritabanına ihtiyaç duydu

Ne yaşandı

Olay odaklı fonksiyon çalıştırma platformu Inngest, 20 Ekim 2026'da iki kesinti penceresi yaşadı: 13:00–13:15 UTC ve 15:20–15:35 UTC. Şirketin incident raporuna ve dev.to'daki bir yazının özetine göre, her iki pencerede de event gönderimleri başarısız olabiliyor ya da zaman aşımına uğrayabiliyordu, fonksiyon planlaması gecikmeye giriyordu ve execution ile checkpoint istekleri normalden yavaştı; event ingestion her pencerenin bir bölümünde tamamen kullanılamaz hale geldi.

Inngest, her iki pencerenin kaynağını tek bir soruna bağladı: uygulama altyapısı ile veritabanı arasındaki bağlantının kaybolması. Veritabanına giden istekler takıldı ve ona bağlı her operasyon — planlama, execution ve checkpoint dahil — birlikte yavaşladı.

Kurtarma yolu işleri nasıl kötüleştirdi

Kısa bir aksamayı iki ayrı kesintiye dönüştüren detay bundan sonra ortaya çıktı. Kesinti sırasında Inngest'in event ingestion servisleri kullanılabilir belleklerini tüketti ve kendilerini yeniden başlattı — normal koşullarda dayanıklı bir sistemden beklediğiniz davranış tam olarak buydu. Sorun şuydu ki bu servislerin başlangıç dizisi de tamamlanmak için başarılı bir veritabanı bağlantısı gerektiriyordu.

O bağlantı hâlâ kopuktu. Bu nedenle yeniden başlatılan instance'lar açılışlarını tamamlayamadı ve servis katmanı kendini onarmayı denemiş olsa bile event ingestion, bağlantı sorunu sürdüğü sürece kapalı kaldı. dev.to'daki yazıya göre Inngest'in kendi analizi, birbirini güçlendiren iki dayanıklılık açığı tespit ediyor: yük altında bellek tükenmesi ve kesintinin devre dışı bıraktığı kaynağın aynısına bağımlı bir kurtarma prosedürü.

Raporun açık bıraktığı nokta

Inngest'in yazısı, veritabanı bağlantı kesintisinin ilk olarak neyin tetiklediğini söylemiyor; yalnızca ona verilen yanıtın etkiyi nasıl büyüttüğünü anlatıyor. dev.to makalesinin de belirttiği gibi, bu eksiklik tetikleyicinin Inngest'te mi, bulut sağlayıcısında mı yoksa ikisi arasındaki ağ yolunda bir yerde mi olduğunu anlamanızı imkânsız kılıyor.

Yazıya göre bu, Inngest'in Ekim 2026'da yayımladığı üçüncü incident raporu; yazı, 9 ve 10 Ekim için bildirilen önceki veri merkeziler arası ve connection-pooler arızalarına da atıf yapıyor. Yazarın savunduğu üzere, üçünün ortak tekrarlayan örüntüsü, dayanıklılık sağlamak için tasarlanmış ama sonuçta bir kesintinin sona ermesi için aşması gereken tek yola dönüşen mekanizma.

Neden önemli

Bu olay, birçok dağıtık sistemde görülen bir arıza modunun kompakt bir örneği: absorbe etmesi gereken arızayla sessizce aynı bağımlılığı paylaşan bir kurtarma mekanizması. Otomatik yeniden başlatma, yeniden başlamayı tamamlamak için neye ihtiyaç duyuyorsa ancak o kadar iyidir; ve o gereklilik, kesintinin çoktan devre dışı bıraktığı bileşenin kendisiyse yeniden başlatma olayı kısaltmaz, uzatır.

Yazıdan uyarlanan birkaç kontrolü kendi altyapınızda uygulamak faydalı olabilir:

• Kaynak tükenmesinde otomatik olarak yeniden başlayan her servisi listeleyin ve başlangıç dizisinin kendini sağlıklı ilan etmeden önce ne gerektirdiğini inceleyin.
• Bu bağımlılıkların her biri için, yeniden başlatmayı tetikleyecek kadar şiddetli bir kesintinin aynı zamanda o bağımlılığı da devre dışı bırakıp bırakamayacağını sorun.
• Bir servis belirli bir downstream bağlantısı olmadan başlayamıyorsa, tamamen engellemek yerine açılıp işleri yerel olarak tamponlayabileceği bir degraded-start modu değerlendirin.
• Bu olay ikisinin bir kesintinin tüm süresi boyunca ayrışabileceğini gösterdiği için, "servis yeniden başladı" ve "servis kurtarıldı" sinyallerini izlemede ayrı olarak ele alın.