Yoğun Yük Altında Bellek Sınırlı HTML'den PDF'e Mimarisi
Tek kişilik bir PDF servisi, Postgres kuyruğu ve akışlı Chromium render'ıyla bellek kullanımını belge boyutundan bağımsız sabit tutuyor.
PDF üretmek tek başına kolay bir problem; zor olan, belge boyutunun 50 KB ile yüzlerce megabayt arasında değişebildiği, trafiğin aniden patladığı, içeriğin hassas veri taşıdığı ve tek kişilik bir ekip tarafından işletilmesi gereken üretim mimarisini kurmak. DocPenny, bu dört kısıtı temel alarak on iki haftada tek kişi tarafından geliştirilmiş: SvelteKit, Hono, Postgres üzerinde çalışan pg-boss, Chromium ve S3 uyumlu depolama; Redis, Kafka veya Kubernetes yok.
Mimarinin can alıcı noktası, kuyruğun kabul hızını render hızından ayırması. API saniyede ~5.900 belge kabul edebilirken Chromium saniyede yalnızca ~63 belge render ediyor; bu 90 kat fark bir kusur değil, tasarımın kendisi. Kuyruk trafik patlamalarını yutuyor, worker'lar kendi hızında tüketiyor, hiçbir iş kaybolmuyor.
Bellek kullanımı da benzer şekilde tasarımla sınırlandırılmış: Chrome DevTools Protocol'ün printToPDF çağrısı akış modunda çalıştırılıyor, Node tarafında backpressure destekli bir Readable ile 1 MB'lık parçalar okunuyor ve doğrudan S3 multipart upload'a akıtılıyor. Sonuç, belge boyutundan bağımsız olarak sabit ~20 MB'lık bir bellek tavanı. Güvenlik tarafında şablonlar (yapı) ile veri (JSON payload) ayrılıyor; veri AES-256-GCM ile, her seferinde HKDF türetilmiş anahtarla şifreleniyor, webhook'lar HMAC ile imzalanıyor ve içerikler kısa süreli TTL ile siliniyor.
Tüm bu sistem, aylık yaklaşık 45 avroluk paylaşılan bir sunucu diliminde çalışıyor. Minimal bağımlılıklı yığınla tek kişilik SaaS işletmenin nasıl sürdürülebilir hale getirilebileceğini gösteren somut bir örnek.