01Edge runtime aslında nedirWhat an edge runtime actually is
Edge fonksiyonu, kullanıcıya en yakın veri merkezinde çalışan küçük bir kod parçasıdır — ama onu farklı kılan coğrafya değil, çalışma modelidir. Cloudflare Workers ve benzeri platformlar container ya da VM yerine V8 isolate kullanır: aynı process içinde milisaniyeler içinde başlayan, birbirinden yalıtılmış hafif bağlamlar. Container tabanlı serverless'ta yüzlerce milisaniyeyi bulabilen cold start maliyeti burada pratikte hissedilmez.
An edge function is a small piece of code running in the data center nearest the user — but what makes it different isn't geography, it's the execution model. Cloudflare Workers and similar platforms use V8 isolates instead of containers or VMs: lightweight, mutually isolated contexts that start in milliseconds inside a shared process. The cold start cost that can reach hundreds of milliseconds in container-based serverless is practically imperceptible here.
Bu hızın bedeli kısıtlardır: sıkı CPU süresi ve bellek limitleri, uzun ömürlü process yok, istek bittikten sonra arka planda yaşamaya devam eden iş yok, çoğu platformda ham TCP bağlantısı ve native modül yok. Edge runtime'ı "küçük bir sunucu" gibi düşünmek en yaygın hata; o bir sunucu değil, istek başına çalışan kısa ömürlü bir fonksiyondur. Saatlerce açık kalan bir WebSocket ya da dakikalar süren bir batch işi tutmak istiyorsanız da yanlış katmandasınız — bu işlerin yeri hâlâ klasik bir servis.
The price of that speed is constraints: hard CPU-time and memory limits, no long-lived processes, no work that keeps running after the request ends, and on most platforms no raw TCP connections or native modules. Thinking of an edge runtime as "a small server" is the most common mistake; it isn't a server, it's a short-lived function that runs per request.
Edge bir yer değil, bir kısıtlar kümesidir.
The edge isn't a place. It's a set of constraints.
02Edge'de gerçekten kazanan işlerWhat genuinely wins at the edge
Bu kısıtlar bazı işler için mükemmel uyum demektir: veriye dokunmayan, istek başına milisaniyeler süren, dünyanın her yerinden çağrılan işler.
Those constraints are a perfect fit for certain work: jobs that don't touch data, take milliseconds per request, and get called from everywhere.
- Statik servis + ince API katmanı. HTML, JS ve görseller zaten CDN'de; yanına form gönderimi, webhook ya da küçük bir proxy için ayrı sunucu gerekmez.
- Static serving + a thin API layer. HTML, JS and images already live on the CDN; a form handler, a webhook or a small proxy next to them doesn't need its own server.
- Auth ve session kontrolü. Token doğrulamak, imza kontrol etmek, yetkisiz isteği origin'e hiç ulaşmadan geri çevirmek.
- Auth and session checks. Verifying tokens, checking signatures, and turning away unauthorized requests before they ever reach the origin.
- Redirect, rewrite ve A/B ataması. Kullanıcıyı cookie ile bir varyanta atamak, eski URL'leri yönlendirmek, isteği origin'e gitmeden şekillendirmek.
- Redirects, rewrites and A/B assignment. Assigning a user to a variant with a cookie, redirecting legacy URLs, shaping the request before it travels to the origin.
- Coğrafi kişiselleştirme. İsteğin geldiği ülkeye göre dil, para birimi ya da içerik seçmek — bilgi zaten istekle birlikte geliyor.
- Geolocation personalization. Picking language, currency or content by the request's country — the information already arrives with the request.
Bu site de tam olarak böyle çalışıyor: Cloudflare Pages üzerinde statik dosyalar, iletişim formunu karşılayan tek bir function. Ne container var ne sunucu — olmayan sunucunun bakımı da yok.
This very site runs exactly this way: static files on Cloudflare Pages, with a single function handling the contact form. No container, no server — and no maintenance for the server that doesn't exist.
03Veri yerçekimi: gecikme yok olmaz, taşınırData gravity: latency doesn't vanish, it moves
Edge'in en pahalı yanılgısı, fonksiyonu kullanıcıya taşıyıp veritabanını tek bölgede bırakmaktır. İstanbul'daki kullanıcıya 15 ms mesafede çalışan fonksiyon, us-east-1'deki veritabanına her sorguda ~140 ms gidip geliyorsa ve sayfa üç sorgu istiyorsa, "edge" etiketi sadece faturada kalır. Buna veri yerçekimi denir: kod hafiftir, taşınır; veri ağırdır, kodu kendine çeker.
The most expensive edge illusion is moving the function to the user while leaving the database in one region. If a function running 15 ms from a user in Istanbul makes a ~140 ms round-trip to a database in us-east-1 on every query, and the page needs three queries, the "edge" label survives only on the invoice. This is data gravity: code is light and moves easily; data is heavy and pulls the code toward it.
# İstanbul'dan gelen istek / request from Istanbul edge fn (IST): ~15ms DB (us-east-1) ×3: ~140ms # RTT her sorgu / per query toplam / total: ~435ms # gecikme taşındı, azalmadı / moved, not reduced
Çözüm, veriyi de kullanıcıya yaklaştırmak — ve her seçeneğin bir tutarlılık bedeli var. Replike KV depoları okumada çok hızlıdır ama eventual consistency verir; yazdığınız değeri başka bir bölge saniyeler sonra görebilir. Durable Objects tarzı "kullanıcıya yakın durum" güçlü tutarlılık sunar ama her nesne tek lokasyonda yaşar. Read replica'lar okuma yükünü coğrafyaya dağıtır, yazmalar yine tek merkeze gider. Hangisini seçeceğiniz teknik zevk meselesi değil, ürününüzün bayat okumaya ne kadar tolerans gösterdiği sorusudur. Kararı ürünün diliyle verin: bir blog yazısının beş saniye eski görünmesi sorun değildir; bir stok sayısının ya da bakiyenin eski görünmesi sorundur.
The fix is to move the data closer to the user too — and every option carries a consistency price. Replicated KV stores are very fast to read but give you eventual consistency; a value you just wrote may take seconds to appear in another region. Durable-Objects-style "state near the user" offers strong consistency, but each object lives in a single location. Read replicas spread read load across geographies while writes still travel to one primary. Which one you pick isn't a matter of taste — it's a question of how much stale reading your product can tolerate.
04Sıkıcı sunucunun haklı olduğu yerWhere the boring server is right
Bazen doğru cevap hiç edge olmamasıdır. Kullanıcılarınızın çoğu tek coğrafyadaysa — Türkiye pazarına hizmet veren bir ürünün Frankfurt'taki tek sunucusu gibi — network gecikmesi zaten küçüktür ve p95'inizi belirleyen şey veritabanı sorgularınızdır. Transaction ağırlıklı, ilişkisel veri modeli olan bir uygulamayı onlarca bölgeye yaymak hız değil, dağıtık sistem problemi satın almaktır.
Sometimes the right answer is no edge at all. If most of your users sit in one geography — like a product serving the Türkiye market from a single server in Frankfurt — network latency is already small, and what defines your p95 is your database queries. Spreading a transaction-heavy, relational application across dozens of regions doesn't buy speed; it buys a distributed-systems problem.
Sıkıcı tek bölgeli sunucu; tek transaction sınırı, tek log akışı, tek zihinsel model demektir. Edge'i buna eklemenin en iyi yolu her şeyi taşımak değil: statik içeriği ve kimlik katmanını kenara alın, veriye dokunan çekirdeği merkezde bırakın. Mimari kararın ölçüsü etiketin havalı olması değil, kullanıcının hissettiği milisaniyedir.
A boring single-region server means one transaction boundary, one log stream, one mental model. The best way to add the edge to it isn't to move everything: push static content and the identity layer outward, keep the data-touching core central. The measure of the architectural decision isn't how good the label sounds — it's the milliseconds the user actually feels.