Edge computing kararı "daha hızlı olur mu" sorusuyla verilmiyor. Doğru soru şu: isteğin cevabı veritabanına gitmeden üretilebiliyor mu? Üretilebiliyorsa uçta çalıştırmak gerçekten kazandırıyor. Üretilemiyorsa, kullanıcıya yakın bir yerde çalışan kod, veritabanının bulunduğu bölgeye gidip gelen ek bir durak ekliyor ve sistem yavaşlıyor.
Bu yazı o ayrımı, gerçek platform limitleriyle ve Türkçe kaynaklarda geçmeyen KVKK boyutuyla anlatıyor.
Uçta çalıştırılabilecek işler kısa bir liste
Kriter tek: işin kendi kendine yetmesi. Uçta mantıklı olanlar:
- İmzalı token doğrulama. JWT imzasını kontrol etmek için veritabanı gerekmiyor; geçersiz isteği kullanıcıya en yakın noktada reddetmek, origin'e giden trafiği doğrudan azaltıyor.
- Yönlendirme ve rewrite. Ülke, dil, cihaz veya A/B grubuna göre rota seçmek.
- Hız sınırlama ve bot filtresi. Kötü trafiği origin'e ulaşmadan kesmek.
- Başlık düzenleme. Güvenlik başlıkları, CSP, önbellek direktifleri.
- Görsel dönüştürme ve önbellekleme. Boyut ve format uyarlaması.
- Kişiselleştirilmiş HTML parçası birleştirme, veri zaten uçta önbellekliyse.
Uçta mantıksız olanlar da aynı kriterden çıkıyor: sipariş oluşturma, stok düşme, ödeme, rapor sorgusu, kullanıcı profili okuma. Hepsi merkezî veriye dokunuyor. Bunları uca taşımak, gecikmeyi kullanıcı ile origin arasından uç ile origin arasına kaydırmaktan başka bir şey yapmıyor.
En pahalı yanılgı: "uygulamayı edge'e taşıdık, veritabanı Frankfurt'ta kalsın." İstanbul'daki kullanıcının isteği İstanbul PoP'una düşüyor, oradan Frankfurt'a gidiyor, dönüyor. Aynı uygulamayı tek bölgede, veritabanının yanında çalıştırsanız aynı gidiş-dönüşü bir kez ödüyordunuz. Uçta durum taşıyan bir iş yapıyorsanız veri de uçta olmalı; olamıyorsa o iş uca ait değil.
Limitler karar verdirir: Cloudflare Workers örneği
Uç çalışma zamanları sunucu değil. Mimari kararı verirken bakılacak sayılar (bkz. Cloudflare Workers, Limits):
| Sınır | Ücretsiz | Ücretli | Neyi imkânsız kılar |
|---|---|---|---|
| CPU süresi (HTTP isteği) | 10 ms | 5 dk (varsayılan 30 sn) | Ağır şablon render'ı, büyük JSON dönüşümü, kriptografik toplu iş |
| Bellek | 128 MB (isolate başına) | Büyük dosyayı belleğe alma; akış (stream) kullanmak zorunlu | |
| Alt istek (subrequest) | 50 / istek | 10.000 / istek | Ücretsiz planda "mikroservis çağrılarını uçta birleştirme" deseni |
| URL uzunluğu | 16 KB | Uzun imzalı URL'ler ve büyük query string'ler | |
| Başlıklar (istek/yanıt) | toplam 128 KB | Şişmiş çerez setleri | |
| Cron Trigger / Queue Consumer | 15 dk | Uzun toplu işler; bunları uca değil arka plana verin | |
| Ortam değişkeni | 64 / Worker | 128 / Worker | Her biri 5 KB; büyük yapılandırmayı env'e sığdırma |
| Script boyutu | 64 MiB (sıkıştırılmamış) | Ağır bağımlılık ağaçları | |
Bu tablodaki en belirleyici satır ücretsiz plandaki 10 ms CPU. Prototipi ücretsiz planda kuran ekipler, üretimde ücretli plana geçince limitin 30 saniyeye çıktığını görüp rahatlıyor; oysa asıl mesaj şu: uç çalışma zamanı CPU süresini ölçen bir ortam. Beklemede geçen süre (I/O) sayılmıyor ama hesaplama sayılıyor. Kod yazarken "kaç milisaniye CPU harcıyorum" sorusunu ilk kez burada sormak zorunda kalıyorsunuz.
KVKK: uçta işlemek, çoğu zaman yurt dışına aktarmaktır
Bu, Türkçe edge yazılarında neredeyse hiç geçmeyen ama en bağlayıcı kısım. Global bir uç ağında kodunuz kullanıcıya en yakın noktada çalışıyor; yani Türkiye'den gelen istek için Türkiye'de, başka bir yerden gelen için başka bir ülkede. İstek içinde kişisel veri varsa (IP, çerez kimliği, kullanıcı adı, sipariş bilgisi) ve işleme yurt dışındaki bir noktada gerçekleşiyorsa, bu KVKK açısından yurt dışına aktarım.
6698 sayılı Kanun'un 9. maddesi (2/3/2024 tarihli 7499 sayılı Kanun'la değişik) üç kademeli bir yapı kuruyor:
- Yeterlilik kararı. Kurul tarafından verilir ve Resmî Gazete'de yayımlanır; en geç dört yılda bir değerlendirilir. Varsa, md. 5 ve 6'daki şartlardan birinin varlığıyla aktarım yapılabilir.
- Uygun güvenceler. Yeterlilik kararı yoksa; Kurul iznine bağlı uluslararası nitelikte olmayan anlaşma, Kurul onaylı bağlayıcı şirket kuralları, Kurulca ilan edilen standart sözleşme, veya Kurul izinli taahhütname. Standart sözleşme, imzalanmasından itibaren beş iş günü içinde Kuruma bildirilir.
- Arızi haller (md. 9/6). Yeterlilik kararı ve uygun güvence yoksa yalnızca arızi olmak kaydıyla; açık rıza, sözleşmenin ifası, üstün kamu yararı gibi sayılı haller. "Arızi" kelimesi burada belirleyici: süreklilik arz eden bir uç mimarisi bu fıkraya dayandırılamaz.
Pratik sonuç: uç katmanını yalnızca kişisel veri taşımayan işler için kullanmak, uyum yükünü sıfıra indiriyor. Statik varlık dağıtımı, önbellek, yönlendirme kuralı ve imza doğrulaması bu kapsamda kalabiliyor. Kişiselleştirme, oturum yönetimi ve form işleme uca taşındığı anda hukuki analiz gerekiyor. Bankacılık ve sağlık gibi sektörel mevzuatı olan alanlarda ise ek kısıtlar var; bunları kendi düzenleyicinizin metninden teyit edin.
Endüstriyel uç, web uçtan tamamen farklı bir şey
"Edge computing" terimi iki ayrı dünyada kullanılıyor ve karıştırıldığında yanlış ürün satın alınıyor. Web tarafında uç, CDN noktalarında çalışan kısa ömürlü fonksiyonlar. Endüstride uç, fabrikadaki gateway veya endüstriyel PC; amacı gecikme değil, bağlantı kopukken üretimin durmaması ve ham verinin buluta taşınmadan azaltılması.
Endüstriyel uçta sorulacak sorular da farklı: gateway kesinti sırasında kaç saatlik veriyi tamponluyor, bağlantı gelince sıralı mı gönderiyor, ve karar mantığı (alarm eşiği, durdurma kararı) uçta mı bulutta mı? Karar mantığı buluttaysa, internet kopunca hat karar veremez hâle geliyor. Bu ayrımı kabul testine yazın.
Karar akışı
| Soru | Cevap "hayır" ise |
|---|---|
| İş, merkezî veritabanına dokunmadan tamamlanabiliyor mu? | Uca taşımayın; tek bölgede, veriye yakın çalıştırın |
| İşlenen veri kişisel veri olmaktan çıkarılabiliyor mu? | KVKK md. 9 analizi yapın; yeterlilik kararı yoksa standart sözleşme yolunu kurun |
| İş, tek istekte 10-30 ms CPU altında bitiyor mu? | Uç çalışma zamanı yanlış araç; arka plan işine veya origin'e alın |
| Ölçüm yapabiliyor musunuz (öncesi/sonrası p75 gecikme)? | Taşımadan önce ölçün; kazancı olmayan taşıma sadece karmaşıklık ekler |
Önce yapılacak ölçüm
Uç mimarisi kurmadan önce tek bir veri toplayın: origin yanıt sürenizin ne kadarı ağ, ne kadarı uygulama? Sunucunuz isteği 400 ms'de işliyorsa, kullanıcıya 30 ms yaklaşmanın anlamı yok; önce o 400 ms'ye bakın.
Bu ayrımı yapmadan alınan uç kararları, yavaş sorgunun üstüne bir katman daha ekliyor ve hata ayıklamayı zorlaştırıyor.
Bulut tarafındaki geçiş kararları için bulut migrasyonu, mimari bölünme için mikroservis mi monolit mi, endüstriyel uç için akıllı fabrika ve MQTT yazılarına bakabilirsiniz. Altyapı tarafındaki çalışma biçimimiz DevOps ve altyapı sayfasında; mevcut mimarinizi konuşmak için iletişim sayfasından yazabilirsiniz.
Platform limitleri 25 Eylül 2026'da Cloudflare Workers "Limits" dokümanından, yurt dışına aktarım kuralları 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 9. maddesinden (2/3/2024 tarihli 7499 sayılı Kanun'la değişik) doğrulanmıştır. Diğer uç platformlarının limitleri farklıdır ve kendi dokümanlarından teyit edilmelidir. Yurt dışına aktarım analizi hukuk danışmanınızla yapılmalıdır.
