Apinizer AI Gateway'in Hikâyesi: Ayrı Bir Kutu Kurmadık, Bir Sınırı Yeniden Çizdik
Farklılaşan data path, bölünmeyen control plane.
Sonuç
Apinizer AI Gateway bugün yayında. 17'den fazla LLM sağlayıcısı tek bir OpenAI-uyumlu endpoint arkasında; token ve maliyet bütçeleri, prompt firewall, PII maskeleme, MCP ve A2A yönetişimi — hepsi REST API'lerinizi zaten koşturan gateway'in üzerinde. Ayrı bir konsol yok, ayrı bir kimlik sistemi yok, ayrı bir nöbet listesi yok.
Ama bu yazı bir özellik listesi değil. Asıl anlatmak istediğim şey başka: bu ürünü neden ikinci bir kutu olarak değil, mevcut gateway'in içinde kurduk? Ve on beş ay önce kendimize yazdığımız bir uyarı bu kararı nasıl şekillendirdi?
Piyasanın önerdiği yol
LLM'ler kurumsal sistemlere girdiğinde piyasanın önerisi netti: API'leriniz için bir gateway'iniz var, AI trafiğiniz için ayrı bir AI Gateway alın. İkinci bir konsol, ikinci bir deploy hattı, ikinci bir vendor, ikinci bir nöbet listesi.
Biz bu ürünü kurarken aynı yoldan gitmedik. Ama bu karara aceleyle varmadık — çünkü on beş ay önce, henüz AI modülünü tasarlamaya başlamamışken, kendimize bunun tam tersi bir uyarı yapmıştık.
Kendi uyarımız: Nisan 2025
Nisan 2025'te Gateway Hayvanat Bahçesi: Conway Yasası Perspektifinden API, Event, Kafka, AI Gateway'ler başlıklı bir yazı yazdık. Conway Yasası'ndan hareket ediyordu: "Sistemleri tasarlayan organizasyonlar, kendi iletişim yapılarını yansıtan tasarımlar üretmeye mahkumdur."
O yazının kaygısı şuydu: API Gateway'lerin kapsamı Event Gateway, Kafka Gateway, AI Gateway, Agent Gateway gibi kavramlarla sürekli genişletiliyordu. Bu genişleme, geçmişin ESB'lerinin (Enterprise Service Bus) düştüğü tuzağı yeniden doğurma riski taşıyordu — "her şeyi çözen tek araç" olma iddiasıyla büyüyüp, iş mantığının sızdığı, zamanla hantallaşan, değişim önünde engele dönüşen bir monolit.
Vardığımız sonuç netti: büyük ölçekli ve uzun ömürlü sistemlerde farklı işlevler, iyi tanımlanmış arayüzlerle birbirine bağlanan ayrı bileşenler olarak tasarlanmalı — her şey tek runtime'a yığılmamalı. O gün Agent Gateway hâlâ teorik bir kategoriydi. Bir ürün kararı verecek olsaydık, bu yazı bizi "ayrı bir AI Gateway kur" tarafına iterdi.
Fiilen AI modülünü tasarlamaya oturduğumuzda, iş tam da bu disiplinle başladı: kendi yazdığımız uyarıyı ciddiye almak. Soru "AI'yı nereye koyalım" değildi; "gateway sprawl'a düşmeden bunu nasıl doğru kurarız" idi.
LLM'ler geldi, soru keskinleşti
Kurumsal yazılımda API'leri tek kapıdan yönetmek uzun süredir API Gateway'in işiydi: kimlik doğrulama, kota, log, routing, güvenlik politikaları. Sonra uygulamalar sadece REST endpoint'ine değil; OpenAI'ye, Anthropic'e, Azure'a, Bedrock'a, kendi barındırılan modellere konuşmaya başladı. Aynı anda birden fazla model, streaming yanıtlar, token bazlı maliyet, prompt injection riski, şirket dokümanına dayalı cevap ihtiyacı.
Üç sahne, klasik API Gateway'in neden tek başına yetmediğini özetliyordu:
Sağlayıcı değişimi operasyonu kırıyor. Ekip GPT ile başlıyor, maliyet artınca kendi barındırdığı bir modele bakıyor, regülasyon gelince başka bir buluta geçmek istiyor. Her seferinde istemci kodu, key yönetimi, hata handling yeniden yazılıyor.
Asıl fatura istek sayısı değil, token. Ay sonunda "API çağrısı az" görünüyor ama fatura şişmiş oluyor — uzun prompt'lar, şişmiş context, sessiz retry'ler token'ı yakmış. Klasik API'de TPS çoğu zaman yeter; LLM'de görünürlük token'a, modele, maliyete kayıyor.
Güvenlik uygulama koduna bırakılamıyor. Bir chatbot'a şirket prosedürü system prompt'una yapıştırılıyor, PII maskesiz modele gidiyor, prompt injection kimsenin aklına gelmiyor. Model bilmediği maddede uyduruyor; "çalışıyor" sanılıyor.
Bu üç sahne aynı sonuca çıkıyordu: LLM trafiği "normal API" değil. Bir kontrol katmanına ihtiyaç vardı. Ama Nisan'daki kendi uyarımız hâlâ masadaydı — peki bu kontrol katmanı ayrı bir ürün mü olmalıydı?
Sınırı nereye çizdik
Burada bir varsayımı sorguladık: "ayrı ürün mü, entegre mi" sorusu yanlış eksendeydi. Asıl soru şuydu — neyin farklılaşması, neyin birleşik kalması gerekiyor?
ESB tuzağı, işlevlerin çalışma zamanında ve sorumluluk sınırında birbirine karışmasıydı: tek runtime, içine sızmış iş mantığı, değişemeyen bir monolit. Ama LLM trafiğiyle birlikte ortaya çıkan risk bunun tam tersiydi: her AI aracının kendi kullanıcı yönetimini, kendi log formatını, kendi anahtar deposunu getirmesi — yönetişimin parçalanması. Bunların birine hantallık, ötekine shadow IT denir.
Bu ikisi aynı eksende durmuyordu. Ayrılması gereken şey data path'in teknik karakteristiğiydi — streaming, TTFT, token ekonomisi, uzun süre açık kalan bağlantılar klasik REST'in milisaniye seviyesindeki request/response döngüsüyle kıyaslanamazdı, bunu görmezden gelemezdik. Ama birleşmesi gereken şey control plane'di: kimlik, policy, deploy, audit, analytics. Bunlar bölündüğünde platform ekibi ikinci bir kimlik sistemi, ikinci bir audit hattı, ikinci bir nöbet listesiyle uğraşmak zorunda kalıyordu — bu maliyet, LLM trafiğinin teknik zorunluluğundan değil, ayrı bir konsol, ayrı bir kimlik yönetimi, ayrı bir audit hattı olarak paketlenmesinden doğuyordu.
Burada gözden kaçırılmaması gereken bir ayrım var: data path'in farklılaşması gerektiği doğru, ama bu farklılaşmayı kimin üstleneceği ayrı bir soru. Müşterinin bunun için ikinci bir runtime kurması, ikinci bir altyapı işletmesi gerekmiyor — bu işi biz ürünün içinde, tek platformun arkasında hallediyoruz. Dışarıdan bakan ekip tek bir gateway, tek bir konsol görüyor; streaming'e özel connection handling, backpressure ve timeout stratejileri o tek ürünün içinde, görünmez şekilde çalışıyor.
Karar buradan çıktı: AI, gateway'de yeni bir ürün değil, yeni bir proxy tipi oldu — REST, SOAP, gRPC'nin yanında birinci sınıf bir vatandaş. Aynı runtime'da koşuyor, aynı Identity Manager'dan (OAuth2/OIDC/JWT/mTLS) doğrulanıyor, aynı Analytics Engine'e log düşüyor, aynı deploy hattından geçiyor. Platform ekibi yeni bir ürün değil, yeni bir sekme öğreniyor.
Nisan'daki uyarı yanlış değildi; hangi eksende ayrım gerektiğini o gün netleştirmemiştik. ESB tuzağı ile gölge IT tuzağı aynı Conway geriliminin iki ucu — biri çalışma zamanının bölünmemesini, öteki yönetişimin bölünmemesini istiyor. İkisini birden karşılamak, kararın kendisiydi.
Data path'te gerçekten ne farklılaştı
Bunu iddia olarak bırakmadık. LLM trafiğinin REST'ten farkını görmezden gelmedik, ürün içinde tek tek çözdük — müşterinin ayrı bir sistem kurmasına gerek kalmadan:
Streaming'de PII sızdırmıyor. Bir kimlik numarası tam da chunk sınırında ikiye bölünürse ne olur? Naif bir maskeleyici her paketi tek başına tarar, hiçbirinde "tam desen" göremez, ikisi de sızar. Kayan pencereyle çözdük — yarım kalan bir desen bir sonraki chunk'a taşınıyor, tüm yanıtı tamponlamadan. Hız korunuyor, gizlilik de.
Bütçe bir rapor değil, bir kapı. Token harcamasını ay sonunda öğrenmek yerine ön-rezervasyonla çalışıyoruz: istek gelince tahmini maliyet önden ayrılır, stream bittiğinde gerçekle uzlaştırılır. Dört katmanlı bir hiyerarşi — credential, kuruluş, proxy, proje — %50/80/90/100 eşik alarmlarıyla, aşımda engelleme/ucuz modele düşürme/failover seçenekleriyle.
Cache, maskelemeyi bypass etmiyor. Semantic cache maliyeti düşürür ama yanlış kurulursa tehlikeli bir açık yaratır: maskeleme uygulanmadan önceki ham yanıt cache'e yazılırsa, cache-HIT'te maskeleme hiç çalışmaz. Kural net: cache'lenen şey her zaman kullanıcıya gidecek güvenli hal, ham gövde değil.
Sağlayıcı devre kesici ve failover, istemciyi hiç rahatsız etmiyor. Bir sağlayıcı bozulursa zincirdeki bir sonrakine geçiliyor; istemci aynı OpenAI-uyumlu formatla konuşmaya devam ediyor. Kendi barındırılan modeller de SaaS modellerle aynı havuzda, aynı bütçe ve guard'la yönetiliyor.
Agent döngüsü sınırsız değil. Tool-call feedback loop'ları belirli bir tur sayısıyla sınırlı; kaçak zincirleme yok. Tool sonucu geri geldiğinde tekrar tüm policy zincirinden geçiyor — çünkü risk sadece agent'ın gönderdiğinde değil, dış dünyadan okuyup modele taşıdığında da var.
Bunların hiçbiri "REST gibi davran" değil. Her biri LLM trafiğinin kendine özgü karakteristiğine — token ekonomisi, streaming'in atomik olmayan doğası, agent'ların çift yönlü veri akışı — özel olarak tasarlandı. Farklılaşan data path; bölünmeyen control plane.
Ürün turu: nedenden çözüme
Bugün lanse ettiğimiz ürün, tesadüfen bir araya gelmiş bir özellik listesi değil — her parça yukarıdaki sahnelerden birine cevap.
- Sağlayıcı bağımlılığına karşı: OpenAI-uyumlu tek endpoint arkasında çok sayıda LLM sağlayıcısı, maliyet/gecikme/isteğe göre routing, proaktif failover — uygulama kodu değişmeden sağlayıcı değişir.
- Kontrolsüz maliyete karşı: dört katmanlı, gerçek zamanlı token/USD bütçesi — çağrı gitmeden önce kapı kapanır.
- Prompt'ta tanımlı "sınıra" karşı: konu, injection, context bütünlüğü, DLP ve loop guard'ları — beş ortogonal sinyal, model isteği görmeden önce merkezi bir yerde uygulanır. İnline/async/shadow modlarıyla, yeni bir kuralı önce ölçüp sonra açma imkânıyla.
- Uygulama katmanında duran sağlayıcı anahtarına karşı: sağlayıcı anahtarı gateway'deki model tanımında şifreli saklanır, uygulamalar gateway'e kendi kimlikleriyle bağlanır — gerçek key hiç uygulamaya çıkmaz, rotasyon bir deploy değildir.
- Chatbot'a yapıştırılan şirket dokümanına karşı: RAG, ürün seviyesinde bir yetenek — Knowledge Base, doküman ingestion, multi-tenant izolasyon; prompt'a kopyala-yapıştır değil, yönetilen bir politika.
- "Neden yavaşladığını, nereye para gittiğini göremiyorum" sorusuna karşı: TTFT/TPOT ayrımlı gecikme görünürlüğü, her kayıtta zengin AI alan seti, herhangi bir çağrıyı DAG olarak yeniden oynatabilen trace.
- Agent'ların iki yönlü risk yüzeyine karşı: MCP ve A2A'da hem gönderilenin hem okunanın — tool sonucunun — tüm policy zincirinden geçmesi.
Lansman: bir ürün değil, bir disiplin
Bugün lanse ettiğimiz AI Gateway, on beş ay önce kendimize yaptığımız "gateway sprawl'a düşmeyin" uyarısını çiğnememenin kanıtı: data path gerçekten farklılaşmalı — streaming, token ekonomisi, agent döngüleri bunu zorunlu kılıyor — ama bu farklılaşma için sizin ikinci bir runtime kurmanıza gerek yok, bu ayrımı sizin adınıza biz üstleniyoruz. Control plane'in ise hiç bölünmesi gerekmiyor.
Nisan'da bir olasılık olan Agent Gateway, on beş ay sonra gerçek oldu. Bir sonraki trafik türünün ne olacağını, kapıya hangi protokolün geleceğini bugünden bilmiyoruz. Ama elimizde artık bir soru var, karşımıza her yeni kategori çıktığında soracağımız: burada gerçekten farklılaşması gereken ne, birleşik kalması gereken ne? Apinizer AI Gateway'in cevabı buydu — data path REST'ten ayrıldı, control plane bölünmedi. Bugün lanse ettiğimiz ürün bir kapanış değil; bu soruyu ciddiye almanın ilk somut kanıtı.
Apinizer AI Gateway — ürün sayfası ve teknik detaylar: apinizer.com/products/ai-gateway
Bu yazıda anlatılanların hangi sürümle geldiğini, platformun geri kalanında neler değiştiğini merak edenler için: 2026 sürüm notları
Kavramsal çerçeveyi baştan okumak isteyenler için serinin ilk bölümü: API'leri Nasıl Yönetiyorsak, LLM'leri de Öyle Yönetmeliyiz