Kent C. Dodds, "Call Kent" podcast'inin 226 bölümü boyunca, ses kayıtlarını birleştirme ve nihai MP3 dosyasını oluşturma gibi FFmpeg işlemlerini kentcdodds.com'u barındıran aynı Fly.io makinesinde çalıştırdı. Bu basit bir akıştı ve uzun süre sorunsuz çalıştı. Ancak, bir bölümün beklenenden uzun sürmesi, yayınlama akışında çalışan FFmpeg işinin üretim sunucusunda aşırı CPU doygunluğuna neden oldu. Yük ortalaması %400-500'e fırladı ve sunucu, ayrılan CPU bütçesini tüketerek kısıtlandı. Site performansı düştü ve bu durum, Dodds'ı FFmpeg işlemlerini ana makineden ayırma kararı almaya itti.
Yazar, başlangıçtaki tasarım kararının o dönem için mantıklı olduğunu belirtiyor. FFmpeg işleri yalnızca kendisi tarafından, bölüm başına bir kez tetikleniyordu ve bu nedenle bir iş kuyruğu veya özel bir çalışan havuzu kurmak, o an için var olmayan bir ölçeklenebilirlik sorununu çözmek anlamına gelecekti. "Basit başla ve gerçeklik sana ne yapman gerektiğini söylediğinde geliştir" felsefesiyle hareket ettiğini vurguluyor. Eski tasarımın, genel web trafiği için zaten boyutlandırılmış olan aynı makinede çalışması nedeniyle uzun süre güvenli görünmesinin yanıltıcı bir avantajı da vardı; sorun, ancak ses dosyası yeterince uzun olduğunda ve paylaşılan CPU kotası yetersiz kaldığında ortaya çıktı.
Bu deneyim, Dodds'a Cloudflare Queues ve Containers gibi modern bulut hizmetlerini kullanma fırsatı sundu. FFmpeg'in ana makinede çalışmasının en kötü seçenek olmasının nedeni, kentcdodds.com'un birincil (yazma işlemleri için) ve okuma replikalarıyla Fly.io üzerinde çalışmasıydı. FFmpeg, tüm yazma işlemlerini yöneten birincil makineyle rekabet ederek kritik hizmetlerin performansını olumsuz etkiliyordu. Bu durum, iş yüklerinin ayrıştırılması ve özel kaynaklara atanmasının önemini açıkça ortaya koydu.
Bu makale, basit başlayan ancak ölçeklendikçe sorun yaratan altyapı kararlarının nasıl optimize edilebileceğini ve modern bulut hizmetlerinin bu süreçte nasıl kullanılabileceğini gösteriyor.