> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/api-gateway-nedir-mikroservislerde-neden-kullanilir*

---

# API Gateway Nedir? Mikroservislerde Neden Kullanılır?

*Yayın Tarihi: 2026-10-07 14:00:01*

Mikroservis mimarisinde tek bir kullanıcı işlemi; kimlik, ürün, sipariş, ödeme ve bildirim gibi birden fazla servise dokunabilir. İstemcinin bu servislerin adreslerini, sürümlerini ve güvenlik kurallarını ayrı ayrı bilmesi ise kısa sürede karmaşık bir entegrasyon ağı oluşturur. API gateway, dış istemciler ile arka plandaki servisler arasına yerleşerek bu karmaşıklığı kontrollü bir giriş noktasında toplar.
Bu katmanın görevi yalnızca gelen isteği başka bir sunucuya yönlendirmek değildir. Doğru tasarlandığında yönlendirme, kimlik doğrulama, yetkilendirme, trafik sınırlama, istek birleştirme, protokol dönüştürme ve gözlemlenebilirlik gibi ortak ihtiyaçları merkezi biçimde yönetir. Yanlış tasarlandığında ise bütün sistemin bağımlı olduğu ağır ve kırılgan bir darboğaza dönüşebilir.

## API Gateway Nedir?

API gateway, bir uygulamanın istemcilere açılan API trafiği için merkezi giriş katmanıdır. Mobil uygulama, web arayüzü, iş ortağı sistemi veya üçüncü taraf entegrasyon gelen isteği doğrudan her mikroservise göndermek yerine gateway üzerinden iletir. Gateway isteğin hangi servise gideceğini belirler, gerekli politikaları uygular ve cevabı istemciye döndürür.
Microsoft’un mikroservis mimarisi rehberinde gateway; istemciler ile servisler arasında ters proxy gibi konumlanan, istekleri yönlendirebilen ve kimlik doğrulama, SSL sonlandırma ile rate limiting gibi çapraz sorumlulukları üstlenebilen bir katman olarak açıklanır  [Microsoft Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/microservices/design/gateway). AWS de API Gateway’in trafik yönetimi, yetkilendirme, erişim kontrolü, izleme ve API sürüm yönetimi gibi görevleri ele alabildiğini belirtir  [Amazon API Gateway Documentation](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html).

**Kısa tanım:** API gateway, mikroservislerin kendisi değildir. İstemcinin arka uç servislerine güvenli, tutarlı ve yönetilebilir biçimde ulaşmasını sağlayan sınır katmanıdır.

## Mikroservislerde Neden Bir Giriş Katmanına İhtiyaç Duyulur?

Monolitik bir uygulamada istemci genellikle tek bir backend adresine bağlanır. Mikroservislerde ise aynı iş alanı birçok bağımsız servise ayrılabilir. İstemcinin her servisin konumunu bilmesi; servis keşfi, ağ değişiklikleri, kimlik doğrulama ve hata yönetimi sorumluluğunu frontend tarafına taşır.
Örneğin bir e-ticaret mobil uygulamasındaki “sipariş detayını göster” ekranı sipariş, müşteri, kargo ve ödeme servislerinden veri isteyebilir. Mobil uygulamanın dört servise ayrı bağlantı kurması daha fazla ağ çağrısı, daha karmaşık hata senaryosu ve backend değişikliklerine daha sıkı bağımlılık yaratır. Gateway, istemciye tek ve istikrarlı bir sözleşme sunarken arka taraftaki servis topolojisini gizleyebilir.

- İstemci tek bir API adresiyle çalışır.

- Servislerin iç ağ adresleri dışarıya açılmaz.

- Ortak güvenlik ve trafik politikaları merkezi uygulanabilir.

- Backend servisleri yeniden düzenlenirken istemci sözleşmesi korunabilir.

- Log, metrik ve iz bilgileri ortak bir giriş noktasından toplanabilir.

## API Gateway İstekleri Nasıl Yönlendirir?

Gateway gelen isteğin host, path, HTTP metodu, header, kullanıcı bilgisi veya API sürümü gibi özelliklerine bakarak hedef servisi seçer. Örneğin /api/orders istekleri sipariş servisine, /api/customers istekleri müşteri servisine yönlendirilebilir. Servis instance’ları dinamik olarak değişiyorsa gateway bir servis keşif mekanizması veya load balancer ile birlikte çalışabilir.
Yönlendirme kuralı istemciden backend yapısını ayırır. Sipariş servisinin farklı bir altyapıya taşınması veya yeni sürüme geçirilmesi halinde dış API adresini değiştirmeden gateway kuralı güncellenebilir. Bu yaklaşım kademeli sürüm geçişi, canary yayın ve belirli kullanıcı gruplarını yeni servise yönlendirme gibi senaryolarda da kullanılabilir.

## Kimlik Doğrulama ve Yetkilendirme Nerede Yapılmalı?

Gateway, token doğrulama ve temel erişim politikaları için uygun bir ilk kontrol noktasıdır. İstek üzerindeki JWT, API anahtarı veya başka kimlik bilgileri doğrulanabilir; geçersiz istekler iç servislere ulaşmadan reddedilebilir. Böylece her serviste aynı doğrulama kodunun tekrar edilmesi azalır.
Ancak gateway’de kimliğin doğrulanması, servislerin bütün yetkilendirme sorumluluğunu ortadan kaldırmaz. “Bu kullanıcı sisteme giriş yapmış mı?” sorusu gateway’de çözülebilirken “Bu kullanıcı bu siparişi görmeye yetkili mi?” gibi iş kuralına bağlı kararlar ilgili serviste kalmalıdır. Merkezi katmanın yalnızca kaba erişim kontrolü yapması, domain yetkilerinin ise servislerde korunması daha güvenli bir ayrım sağlar.
Kurumsal projelerde gateway tasarımı, yalnızca bir ürün kurulumu değil; kimlik akışı, servis sözleşmeleri ve [API entegrasyon mimarisi](/api-entegrasyon-hizmeti) ile birlikte ele alınması gereken bir karardır.

## Rate Limiting Mikroservisleri Nasıl Korur?

Rate limiting, belirli bir istemcinin belirli sürede yapabileceği istek sayısını sınırlar. Amaç yalnızca kötü niyetli trafiği engellemek değildir; hatalı bir mobil sürümün, agresif çalışan entegrasyonun veya beklenmeyen trafik artışının backend kapasitesini tüketmesini önlemektir.
Gateway kullanıcı, IP adresi, API anahtarı, abonelik paketi veya endpoint bazında farklı limitler uygulayabilir. Limit aşıldığında çoğu HTTP API, istemciye 429 durum koduyla cevap verir. AWS API Gateway dokümantasyonu throttling uygulamasında token bucket yaklaşımını kullanır ve hız ile ani trafik kapasitesini ayrı ele alır  [AWS Request Throttling Guide](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html).
Rate limit, backend kapasitesinden bağımsız seçilmemelidir. Çok yüksek limit sistemi korumaz; çok düşük limit ise gerçek kullanıcıları engeller. Kritik endpoint’ler, yüksek maliyetli sorgular ve iş ortağı entegrasyonları için farklı politikalar tanımlanması daha sağlıklıdır.

## Gateway Aggregation Ne İşe Yarar?

Bazı ekranların hazırlanması için birden fazla servisten veri gerekir. Gateway aggregation yaklaşımında istemci tek bir istek gönderir; gateway ilgili servislere çağrı yapar, cevapları birleştirir ve tek cevap üretir. Microsoft bu deseni, çok sayıdaki bireysel isteği gateway üzerinden tek bir istemci isteğinde toplama yaklaşımı olarak tanımlar  [Microsoft Gateway Aggregation Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation).
Bu yöntem özellikle mobil ağlarda istek sayısını azaltabilir ve istemci kodunu sadeleştirebilir. Buna karşılık gateway’in iş mantığıyla dolmasına izin verilmemelidir. Veri birleştirme, biçim dönüştürme ve hafif orkestrasyon makul olabilir; fiyat hesaplama, stok rezervasyonu veya sipariş durumu değiştirme gibi domain kuralları ilgili servislerde kalmalıdır.

Gateway göreviSağladığı faydaDikkat edilmesi gereken riskRoutingİstemciyi doğru servise yönlendirirYanlış kurallar servisleri erişilemez yapabilirAuthenticationGeçersiz trafiği iç ağa ulaşmadan keserDomain yetkilendirmesi gateway’e taşınmamalıRate limitingBackend kapasitesini ve adil kullanımı korurLimitler gerçek trafik ve kapasiteyle uyumlu olmalıAggregationBirden fazla servis çağrısını tek cevapta toplarGateway iş mantığı merkezi haline gelmemeliObservabilityOrtak trafik metrikleri ve erişim logları sağlarHassas veriler loglara kontrolsüz yazılmamalı

## Observability Açısından API Gateway’in Rolü

Mikroservislerde bir hatanın hangi aşamada oluştuğunu bulmak, tek sunuculu uygulamalara göre daha zordur. Gateway dış trafiğin geçtiği ortak nokta olduğu için istek sayısı, hata oranı, gecikme, durum kodları, endpoint kullanımı ve istemci bazlı trafik gibi metriklerin toplanmasında değerlidir.
Gateway logları tek başına uçtan uca görünürlük sağlamaz. Her isteğe correlation ID veya trace context eklenmesi ve bu bilginin servisler arasında taşınması gerekir. Böylece gateway’de başlayan bir isteğin sipariş, ödeme ve bildirim servislerindeki adımları ilişkilendirilebilir. AWS, API Gateway REST API’lerinin CloudWatch metrikleri, logları ve X-Ray üzerinden izlenebildiğini dokümante eder  [AWS API Monitoring Guide](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-monitor.html).
Loglama yapılırken access token, parola, kart bilgisi veya kişisel veri gibi hassas alanlar maskelenmelidir. Gözlemlenebilirlik amacıyla her request ve response body’sini kaydetmek, güvenlik ve veri saklama açısından yeni bir risk yaratabilir.

## API Gateway, Reverse Proxy ve Load Balancer Aynı Şey mi?

Bu kavramların görevleri örtüşebilir ancak odakları aynı değildir. Reverse proxy, istemci adına backend’e istek ileten genel bir ara katmandır. Load balancer, trafiği birden fazla instance arasında dağıtarak kapasite ve süreklilik sağlamaya odaklanır  [NGINX HTTP Load Balancing Documentation](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/). API gateway ise API tüketicileri, endpoint politikaları, kimlik, kota, dönüşüm ve API yaşam döngüsü gibi uygulama katmanı ihtiyaçlarını birlikte yönetir.
Bazı ürünler bu rollerin birkaçını aynı anda üstlenebilir. Bu nedenle karar ürün adından çok ihtiyaç listesine göre verilmelidir. Yalnızca HTTP trafiğini üç uygulama sunucusuna dağıtmak gerekiyorsa tam kapsamlı bir API yönetim katmanı gereksiz olabilir. Çok sayıda tüketici, servis, sürüm ve erişim politikası varsa basit reverse proxy yapılandırması kısa sürede yetersiz kalabilir.

## API Gateway ile Service Mesh Arasındaki Fark Nedir?

API gateway çoğunlukla dış istemcilerden sisteme gelen kuzey-güney trafiğini yönetir. Service mesh ise servislerin kendi aralarındaki doğu-batı trafiğine; karşılıklı TLS, servis kimliği, retry, trafik politikası ve dağıtık izleme gibi özellikler ekler. İkisi birbirinin doğrudan alternatifi değildir ve büyük sistemlerde birlikte kullanılabilir  [Google Cloud API Management and Service Mesh](https://cloud.google.com/blog/products/application-modernization/api-management-and-service-mesh-go-together).
Küçük bir sistemde yalnızca gateway yeterli olabilir. Servis sayısı, ekip sayısı ve iç trafik karmaşıklığı büyüdüğünde service mesh ayrı bir ihtiyaç haline gelir. Her iki katmanı da yalnızca “modern mimari” görünümü için eklemek operasyon maliyetini artırır.

## Backends for Frontends Yaklaşımı Ne Zaman Gerekir?

Tek bir genel gateway; web, mobil, bayi paneli ve iş ortağı API’si gibi farklı istemcilerin ihtiyaçlarını aynı anda karşılamaya çalıştığında karmaşıklaşabilir. Backends for Frontends, her istemci türüne özel backend veya gateway katmanı oluşturarak bu bağımlılığı azaltır. Microsoft bu deseni, farklı kullanıcı arayüzlerinin ihtiyaçlarına göre backend deneyimlerini ayrıştırma yaklaşımı olarak açıklar  [Microsoft Backends for Frontends Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends).
Mobil istemci daha küçük payload ve daha az ağ çağrısı isterken yönetim paneli ayrıntılı veriye ihtiyaç duyabilir. İki istemciyi tek cevap modeline zorlamak yerine ayrı BFF katmanları kullanılabilir. Fakat küçük projelerde BFF eklemek yeni servisler, deployment süreçleri ve sahiplik sorunları doğuracağından gerçek bir ihtiyaç oluşmadan tercih edilmemelidir.

## API Gateway Kullanmanın Riskleri Nelerdir?

Merkezi giriş katmanı önemli faydalar sağlarken sistem çapında yeni bir bağımlılık oluşturur. Gateway erişilemez olduğunda arka plandaki servisler sağlıklı olsa bile dış kullanıcılar sisteme ulaşamayabilir. Bu nedenle yüksek erişilebilirlik, yatay ölçekleme, sağlık kontrolleri ve kontrollü yapılandırma dağıtımı temel gereksinimlerdir.

- **Tek hata noktası:** Birden fazla instance ve uygun failover tasarlanmamışsa bütün API trafiği durabilir.

- **Performans darboğazı:** Ağır dönüşümler ve senkron çağrılar her isteğe ek gecikme getirir.

- **Merkezi monolit:** İş kuralları gateway’e taşındıkça ekiplerin bağımsızlığı azalır.

- **Yapılandırma riski:** Tek bir yanlış routing veya güvenlik politikası birçok servisi etkileyebilir.

- **Vendor lock-in:** Ürüne özgü politikalar ve eklentiler taşınabilirliği zorlaştırabilir.

- **Gizli maliyet:** Lisans, trafik, loglama ve operasyon maliyeti başlangıç tahminini aşabilir.

## Her Projede API Gateway Kullanılmalı mı?

Hayır. Tek backend’e sahip küçük bir uygulamada gateway eklemek çoğu zaman yalnızca yeni bir dağıtım ve hata katmanı oluşturur. Aynı şekilde birkaç dahili servisin tek bir web uygulamasına hizmet verdiği, kimlik ve trafik politikalarının basit olduğu projelerde mevcut reverse proxy yeterli olabilir.
Gateway ihtiyacı genellikle servis ve tüketici çeşitliliği arttığında belirginleşir. Birden fazla mobil/web istemcisi, dış iş ortakları, farklı kimlik yöntemleri, kota ihtiyacı, API sürümleri veya merkezi gözlem gereksinimi varsa gateway anlamlı değer üretir. Mimari karar, mevcut problemin karmaşıklığı ile çözümün getireceği operasyon yükü karşılaştırılarak verilmelidir.

## API Gateway Seçerken Kontrol Edilmesi Gerekenler

Ürün karşılaştırmasına başlamadan önce gereksinim listesi hazırlanmalıdır. Yönetilen bulut hizmeti, Kubernetes tabanlı gateway, açık kaynak proxy veya tam kapsamlı API management platformu aynı problemi farklı operasyon modeliyle çözer.

- REST, GraphQL, gRPC ve WebSocket gibi gereken protokolleri destekliyor mu?

- OAuth 2.0, OpenID Connect, JWT ve API anahtarı politikaları yeterli mi?

- Kullanıcı, plan ve endpoint bazlı rate limit uygulanabiliyor mu?

- OpenTelemetry veya mevcut log ve metrik altyapısıyla entegre oluyor mu?

- Yapılandırmalar kod olarak sürümlenip güvenli biçimde dağıtılabiliyor mu?

- Multi-region, yüksek erişilebilirlik ve yedekleme gereksinimlerini karşılıyor mu?

- Lisans, istek, veri transferi ve log maliyetleri öngörülebiliyor mu?

- Ekip bu ürünü güncelleyecek ve olay anında işletecek yetkinliğe sahip mi?

Gateway, iyi bir [yazılım geliştirme](/yazilim-gelistirme) sürecinin yerine geçmez. API sözleşmesi, hata modeli, servis sınırları ve güvenlik politikaları tutarsızsa merkezi bir ürün yalnızca bu sorunların üzerini örter.

## Sağlıklı Bir API Gateway Tasarımı İçin Uygulama Sırası

Gateway’i bütün özellikleri aynı anda açılan büyük bir platform olarak kurmak yerine, gerçek ihtiyaçlarla aşamalı ilerlemek daha güvenlidir.

- Dışarı açılacak API’leri ve tüketici gruplarını belirleyin.

- Routing kurallarını ve servis sahipliğini açık biçimde dokümante edin.

- Kimlik doğrulama ile domain yetkilendirmesinin sınırını ayırın.

- Backend kapasitesine göre ölçülebilir rate limit politikaları tanımlayın.

- Correlation ID, access log, metrik ve trace akışını kurun.

- Timeout, retry ve hata cevaplarını istemci sözleşmesiyle uyumlu hale getirin.

- Gateway kesintisi, yanlış yapılandırma ve kapasite artışı senaryolarını test edin.

- İş mantığının gateway’e taşınmasını mimari incelemelerle sınırlayın.

## Sonuç: Gateway Bir Ürün Değil, Mimari Sınırdır

API gateway’in temel değeri mikroservis sayısını artırmak değil, istemciler ile servisler arasındaki sınırı yönetilebilir hale getirmektir. Routing, authentication, rate limiting, aggregation ve observability gibi ortak ihtiyaçlar doğru yerde merkezileştirildiğinde servisler kendi iş alanlarına daha fazla odaklanabilir.
Buna karşılık gateway’e gereğinden fazla sorumluluk yüklemek yeni bir dağıtık monolit yaratabilir. Karar verirken “hangi gateway ürünü?” sorusundan önce “hangi problemleri bu sınırda çözmeliyiz, hangileri servislerde kalmalı?” sorusu cevaplanmalıdır.

## API Mimariniz İçin Doğru Sınırları Planlayın
Mikroservis, gateway ve entegrasyon katmanlarının gereksiz karmaşıklık oluşturmadan tasarlanması; mevcut sistem, trafik ve ekip yapısının birlikte değerlendirilmesini gerektirir. Webioo, ihtiyaçlarınıza uygun [özel web yazılım altyapısını](/ozel-web-yazilim-hizmeti) ve API sınırlarını planlamanıza yardımcı olabilir.[Projenizi Değerlendirelim](/iletisim)

## Sıkça Sorulan Sorular

### API gateway tam olarak ne yapar?

API gateway, istemcilerden gelen API isteklerini uygun backend servisine yönlendirir. Ayrıca kimlik doğrulama, erişim kontrolü, rate limiting, istek ve cevap dönüşümü, loglama, metrik toplama ve bazı durumlarda birden fazla servis cevabını birleştirme görevlerini üstlenebilir.

### API gateway olmadan mikroservis kullanılabilir mi?

Evet. Az sayıda servis ve tek istemci bulunan basit sistemlerde istemci doğrudan servislere veya standart bir reverse proxy üzerinden bağlanabilir. Servis, tüketici ve ortak politika sayısı arttığında gateway daha anlamlı hale gelir.

### API gateway ile load balancer arasındaki fark nedir?

Load balancer öncelikle trafiği birden fazla servis instance’ı arasında dağıtır. API gateway ise endpoint yönlendirme, kimlik, kota, dönüşüm, sürüm ve API tüketici politikaları gibi uygulama katmanı ihtiyaçlarını yönetir. Bazı ürünler iki rolü birlikte üstlenebilir.

### Kimlik doğrulamanın tamamı gateway üzerinde mi yapılmalıdır?

Token doğrulama ve genel erişim politikaları gateway’de uygulanabilir. Ancak bir kullanıcının belirli bir siparişi görme veya değiştirme yetkisi gibi domain kuralları ilgili mikroserviste kalmalıdır.

### API gateway sistemi yavaşlatır mı?

Her ara katman küçük bir ek gecikme oluşturur. Hafif routing ve politika işlemlerinde bu maliyet yönetilebilir. Ağır veri dönüşümü, uzun süren aggregation veya yetersiz ölçekleme gateway’i performans darboğazına çevirebilir.

### API gateway ile service mesh birlikte kullanılabilir mi?

Evet. API gateway çoğunlukla dış istemcilerden gelen trafiği, service mesh ise servisler arası iç trafiği yönetir. Büyük mikroservis sistemlerinde iki katman farklı sorumluluklarla birlikte kullanılabilir.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/api-gateway-nedir-mikroservislerde-neden-kullanilir