Edge Functions vs Lambda: Performans farkını net ölçün

Edge tarafında çalışan Edge Functions ile bulutun belirli bölgelerinde çalışan Lambda (serverless) kodu aynı işi yapsa bile performans profili farklı çıkar. Bu farklılıklar; kullanıcıya mesafe (coğrafi gecikme), soğuk başlangıç (cold start), ölçeklenme davranışı, önbellekleme ve çalıştırma modelinden kaynaklanır. Bu rehberde performansı belirleyen bileşenleri parçalara ayıracak, ardından pratik bir test planı ve net karar matrisi vereceğim.

Edge Functions ve Lambda hangi katmanda çalışır?

Edge Functions, isteği kullanıcının bulunduğu yere daha yakın bir noktada karşılayıp kodu çalıştırır. Lambda ise genellikle AWS bölgelerinde (region) çalışır ve istek önce ilgili region’a ulaştıktan sonra fonksiyon tetiklenir.

Bu yüzden performans farkı sadece "sunucu hızlı" meselesi değildir; istek trafiğinin yolu ve kodun tetiklenme zamanı belirleyicidir.

Temel farkları tek ekranda özetleyelim

• Edge Functions: Coğrafi gecikmeyi azaltma hedefi; istemciye daha yakın pop (PoP) noktalarında çalışır.
• Lambda: Bölge (region) bazlı çalışır; kullanıcı uzak kaldıkça ağ gecikmesi artabilir.
• İkisi de autoscaling yapabilir; ancak cold start davranışı ve ölçeklenme eşiği farklı sonuçlar üretir.

Performansı etkileyen 5 faktör (TTFB merkezli)

Aşağıdaki 5 parametre, "Edge mi Lambda mı daha hızlı?" sorusunu tek başına yanıtsız bırakmayacak kadar belirleyicidir. Net ölçüm yapabilmek için her birini ayrı düşünün.

1) Coğrafi gecikme (network latency)

Kullanıcı ile fonksiyonun çalıştığı nokta arasındaki RTT (round-trip time) TTFB’yi doğrudan etkiler. - Kullanıcıya yakın bir edge pop varsa, Ağ gecikmesi düşer. - Lambda kullanılan senaryoda kullanıcı bölgeden uzaktaysa TTFB daha yüksek görülür.

NetKıyas yaklaşımıyla kontrol: Kullanıcıların yoğun olduğu il/ülke ile sağlayıcının kullandığı POP/region konumlarını birlikte değerlendirmeniz gerekir.

2) Cold start (soğuk başlangıç)

Fonksiyonlar trafik azaldığında kaynak azaltılabilir; yeni istek geldiğinde runtime ortamı hazır olmayabilir. Bu da ilk isteklerde gecikme yaratır. - Cold start etkisi, özellikle küçük ve nadir gelen isteklerde daha belirgindir. - Trafik sürekli dalgalanıyorsa sonuçlar karışır; testleri farklı saat dilimlerinde yapın.

3) Çalıştırma süresi (execution time) ve bağımlılıklar

Kodunuzun gerçek çalışma süresi (CPU/IO), dış servis çağrıları, veritabanı erişimi ve paket boyutları farkı büyütür. - Edge’de çalışan fonksiyonlar bazen daha sınırlı runtime veya paket kısıtlarına sahip olabilir. - Lambda tarafında VPC içine girme gibi adımlar ek ağ gecikmesi doğurabilir.

4) Entegrasyon modeli: Cache (önbellek) ve istek işleme

Edge’de bazı işleme noktaları doğal olarak response caching ve varyantlara göre saklama avantajı sağlar. Lambda ise çoğunlukla API gateway / ALB / CDN katmanıyla birlikte çalıştığında önbellek davranışı belirleyici olur.

Net kural: Eğer aynı parametrelerle gelen isteklerin büyük kısmı önbellekten dönebiliyorsa edge tarafı belirgin avantaj sağlayabilir.

5) Ölçeklenme (concurrency) ve kuyruklar

Yoğun anlarda sunucusuz sistemler ölçeklenir; fakat ölçeklenme eşiğinde geçici kuyruklar ve throttling görülebilir. - Trafiğin anlık sıçraması varsa, concurrency limitleri ve retry stratejileri fark yaratır. - Edge’de daha fazla pop ile paralel dağılım potansiyeli daha yüksektir.

Edge vs Lambda: hangi senaryolarda hangi taraf öne çıkar?

Aşağıdaki listeyi "kendi kullanımım hangisine benziyor?" diye düşünerek ilerleyin.

Edge Functions daha çok kazanır

• İstekler küresel/ülke geneline yaygın: Kullanıcıya yakın çalışmak kritik.
• Çok sayıda kısa ve hızlı yanıt: Basit rota/format dönüştürme, küçük JSON üretimi.
• CDN ile birlikte güçlü önbellekleme: Aynı içerik parametreleri sık dönen API’ler.
• Kritik KPI: TTFB ve ilk paket (first byte) süresi.

Lambda daha çok kazanır

• Kod karmaşıklığı yüksek ve bağımlılıklar geniş: Ağır kütüphaneler, spesifik runtime ayarları.
• Veri erişimi ağırlıkla tek region’a bağlı: Örneğin veritabanınız aynı region’da ve edge’e taşımak mümkün değil.
• İş akışı uzun sürüyor: Asıl gecikme kodun yürütülmesinden geliyor; ağ gecikmesi daha az etkiliyor.
• Geniş entegrasyon ekosistemi: AWS servisleriyle yoğun kullanım.

Net performans karşılaştırma tablosu (TTFB odaklı)

Aşağıdaki tablo, "ortalama hızlı" yerine hangi metriğin neyi etkilediğini netleştirir. Sayılar, test kurulumuna göre değişir; bu yüzden burada beklenti profili veriyorum.

Ölçüm planı: Edge ve Lambda farkını kendi trafiğinizde görün

Performans tartışması genelde "forum" seviyesinde kalır. Aşağıdaki plan, veri üretir ve kararınızı netleştirir.

Adım 1: Aynı işi iki farklı yolla karşılaştırın

• Edge fonksiyonunda aynı route ve aynı response formatını üretin.
• Lambda tarafında aynı iş mantığını, aynı dış bağımlılıklarla çalıştırın.
• Kodda sadece altyapı farkı olsun; aksi takdirde kıyas bozulur.

Adım 2: Benzer caching varsayımlarını sabitleyin

• CDN cache açık/kapalı durumunu iki tarafta da aynı yapın.
• Cache varyantlarını (querystring, header, auth durumu) aynı tutun.

Adım 3: Ölçüm metriklerini tek tek toplayın

En az şu ölçümleri alın: - TTFB (time to first byte) - p50 ve p95 latency (yalnızca ortalama kullanmayın) - İlk istek latansı (cold start göstergesi) - 4xx/5xx oranı - Throttle veya retry kaynaklı sapmalar

Adım 4: İki farklı yük senaryosu test edin

1) Düşük trafik: Dakikada az istek, cold start etkisini yakalar. 2) Dalgalı trafik: Kısa süreli pik; concurrency ve kuyruk davranışı görünür.

Adım 5: Trafik bölgesini gerçekçi seçin

• Türkiye kullanıcıları için Türkiye’den ölçüm yapan test trafiği kullanın.
• Eğer global ürünse, en uzak kullanıcı senaryosunu da test edin.

Net karar matrisi: “Ben hangisini seçeyim?”

Aşağıdaki soruları tek tek yanıtlayın. Her soruda "Evet" sayısı hangi tarafa daha çok çıkıyorsa seçim de ona yaklaşır.

Edge Functions lehine sorular

• Kullanıcılar farklı coğrafyalarda ve TTFB hedefim nettir.
• Fonksiyonlar kısa ve deterministic; aynı parametrelerle benzer yanıtlar üretiyor.
• CDN/edge caching ile cache hit oranı yükseltme planım var.

Lambda lehine sorular

• Kod yürütme süresi baskın (çoğu gecikme dış servisten veya CPU işinden geliyor).
• Veritabanım tek region’da ve edge’e uygun tasarım yapamıyorum.
• Geniş paketler ve özel kütüphaneler kullanıyorum.

Sık yapılan hatalar (kıyasın yanlış çıkmasına neden olur)

• Sadece ortalama latency raporlamak: p95’i görmeden cold start ve kuyruğu kaçırırsınız.
• Cache davranışını farklı tutmak: Edge tarafında cache hit, Lambda tarafında miss olursa sonuç tamamen yanlış çıkar.
• Dış servis çağrılarını sabitlememek: Bir testte veritabanı yakın region’da, diğerinde uzaksa gecikme ağdan gelir.
• Ölçümü sadece tek saat yapmak: Gün içi trafik dalgası cold start ve ölçeklenmeyi değiştirir.
• Aynı payload ve aynı header/auth kullanmamak: Varyantlar yanıtı değiştirir, cache’i bozar.

Uygulama önerileri: Hangi optimizasyon önce yapılmalı?

Önce infra seçimi tartışmasından önce, gecikmeyi azaltacak adımları sırayla alın.

1) Hem Edge hem Lambda’da aynı response stratejisi

• İmkan varsa response’u küçük tutun (payload boyutu TTFB’yi etkiler).
• Gereksiz header/metadata üretimini azaltın.

2) Gerektiğinde cache (önbellek) tasarımı

• Önbellek anahtarını (cache key) doğru kurgulayın.
• Auth gerektirmeyen uçlarda public cache, auth gerektiren uçlarda private cache veya session bazlı strateji kullanın.

3) Cold start azaltma taktikleri

• Düşük trafik uçlarında p95’e bakın; soğuk istekler p95’i şişiriyorsa strateji değiştirin.
• Fonksiyon paket boyutunu küçültün; gereksiz bağımlılıkları kaldırın.
• Dış servis çağrılarını paralelleştirin; zamanlama gecikmeyi düşürür.

4) Veritabanı bağlantısı modelini sadeleştirin

• Lambda tarafında VPC içine girme gibi adımlar varsa, veritabanı bağlantı süresi toplam gecikmeye eklenir.
• Edge tarafında veri erişimini minimize edin: Edge’de mümkün olduğunca statik/az dinamik akış tasarlayın.

Sonuç: Net seçim için tek hedef belirleyin

Edge Functions vs Lambda farkını en hızlı şekilde netleştiren yol, tek bir KPI’ye odaklanıp (çoğunlukla TTFB), aynı iş mantığıyla iki altyapıyı düşük trafik + dalgalı trafik senaryolarında ölçmektir. Eğer hedefiniz ilk bayt süresi ve Türkiye kullanıcılarınıza yakın yanıt üretmekse Edge Functions daha sık üstün çıkar; yürütme süresi baskınsa ve veri erişimi tek region’a kilitliyse Lambda daha mantıklı olur. Bu rehberdeki test planını aynen uygulayın; sonuç tablonuzu kendi istek hacminize göre çıkarın ve altyapı seçimini “ölçüm” ile sabitleyin.