AI Çözümlerinde İstemci-Sunucu (Client-Server) Ağ İletişimi

Bir yapay zeka uygulamasında kullanıcı yalnızca mesajını gönderir ve birkaç saniye sonra ekranda yanıtın oluştuğunu görür. Arka tarafta ise DNS çözümlemesinden TLS bağlantısına, API Gateway’den model sunucusuna, streaming akışından hata yönetimine kadar birçok ağ katmanı birlikte çalışır. AI Çözümlerinde İstemci-Sunucu (Client-Server) Ağ İletişimi doğru tasarlanmadığında güçlü bir model bile kullanıcıya yavaş, kararsız ve pahalı bir deneyim sunabilir. Özellikle LLM uygulamalarında streaming yanıt timeout güvenlik ve bağlantı yönetimi klasik web uygulamalarından daha fazla dikkat ister. Bu rehberde AI uygulamalarında client-server mimarisi nasıl kurulur, yapay zeka sistemlerinde istemci sunucu iletişimi nasıl çalışır ve production ortamında hangi protokolün hangi durumda tercih edilmesi gerektiği adım adım ele alınacaktır.

İstemci-Sunucu (Client-Server) Mimarisi Nedir?

Client-server mimarisi, kullanıcı tarafındaki istemcinin bir sunucuya istek gönderdiği ve sunucunun bu isteği işleyerek yanıt döndürdüğü temel dağıtık sistem modelidir. Web tarayıcıları, mobil uygulamalar, masaüstü istemciler ve başka backend servisleri istemci rolünde olabilir. Sunucu tarafı ise authentication, veri erişimi, iş kuralları ve AI provider bağlantısı gibi görevleri üstlenir. Yapay zeka uygulamalarında bu yapı daha önemlidir çünkü model inference süresi klasik API çağrılarına göre daha uzun olabilir. Ayrıca streaming ve yüksek işlem maliyeti bağlantı yönetimini doğrudan kullanıcı deneyiminin parçası haline getirir.

İstemci Nedir?

İstemci kullanıcı veya başka bir sistem adına sunucuya istek gönderen bileşendir. Bir web tarayıcısı istemci olabilir. Mobil uygulama da aynı rolü üstlenebilir. İstemci kullanıcı girdisini toplar ve uygun API formatına dönüştürür. Güvenlik açısından gizli API anahtarlarını istemci üzerinde tutmamak gerekir.

Sunucu Nedir?

Sunucu istemciden gelen isteği kabul eden ve işleyen sistemdir. Authentication ve authorization çoğunlukla burada uygulanır. AI provider veya kurum içi model sunucusuna bağlantı sunucu üzerinden yapılır. Sunucu ayrıca log, maliyet ve rate limit politikalarını yönetebilir. Production mimarisinde bu katman stateless olacak şekilde tasarlanırsa yatay ölçekleme kolaylaşır.

Request–Response Modeli Nasıl Çalışır?

İstemci bir HTTP isteği göndererek işlemi başlatır. Sunucu isteği doğrular ve gerekli iş kurallarını uygular. Daha sonra veritabanı veya LLM servisi gibi diğer bileşenlerle iletişim kurulabilir. İşlem tamamlandığında istemciye yanıt gönderilir. AI uygulamalarında bu yanıt tek parça yerine stream halinde de iletilebilir.

AI Uygulamalarında Client-Server Mimarisi Neden Önemlidir?

AI uygulamalarında backend yalnızca veri taşıyan bir ara katman değildir. Model anahtarlarını korur ve kullanıcının hangi işlemleri yapabileceğini belirler. Prompt ve system instruction burada oluşturulabilir. Rate limit ve maliyet kontrolü yine bu katmanda uygulanır. Model sağlayıcısı değiştiğinde istemci kodunun etkilenmemesi için provider abstraction da backend üzerinde tutulabilir.

Klasik Web Uygulaması ile AI Uygulaması Arasındaki Fark

Klasik web API çağrıları çoğu zaman kısa sürede tamamlanır. LLM istekleri ise saniyeler veya daha uzun süre açık kalabilir. Yanıtın token bazlı üretilmesi streaming ihtiyacını ortaya çıkarır. Aynı istek GPU veya harici provider tarafında ciddi maliyet oluşturabilir. Bu nedenle timeout, cancellation ve connection state yönetimi AI uygulamalarında daha görünür hale gelir.

Uzun Response Süreleri

LLM inference klasik veritabanı sorgusundan daha uzun sürebilir. Kullanıcının tek parça yanıtı beklemesi kötü deneyim yaratır. Reverse proxy timeout değerleri bu süreye uyumlu olmalıdır. Client bağlantısı gereksiz yere açık bırakılmamalıdır. Uzun işlemler gerektiğinde streaming veya asenkron job modeli kullanılabilir.

Streaming

Streaming yanıtın tamamlanmasını beklemeden parçalar halinde istemciye gönderilmesini sağlar. Kullanıcı ilk tokenı daha erken görür. Bu durum algılanan performansı ciddi biçimde iyileştirir. Backend provider stream’ini istemciye aktarabilir. Proxy buffering doğru ayarlanmazsa streaming avantajı kaybolabilir.

Yüksek İşlem Maliyeti

Her model isteği CPU, GPU veya harici API maliyeti oluşturur. Gereksiz retry aynı isteği iki kez çalıştırabilir. Kullanıcı bağlantıyı kapattığında inference devam ederse para ve kaynak boşa harcanır. Cost metering request seviyesinde yapılmalıdır. Rate limit yalnızca istek sayısına değil token tüketimine göre de uygulanabilir.

Token Bazlı Veri Akışı

LLM yanıtı genellikle token dizisi şeklinde üretilir. Her tokenı ayrı network paketi olarak göndermek verimsiz olabilir. Küçük chunk’lar halinde buffering daha iyi denge sağlar. İstemci incremental rendering yapmalıdır. Stream sonunda usage ve done event gibi ek metadata gönderilebilir.

Harici AI Provider Bağımlılığı

Birçok sistem model inference için harici provider kullanır. Bu durumda backend ile provider arasında ek network bağlantısı oluşur. Provider timeout veya rate limit kullanıcı deneyimini etkiler. Fallback modeli bu riski azaltabilir. Uygulamanın provider-specific API’ye doğrudan bağlanmaması uzun vadede geçişi kolaylaştırır.

Bir AI Uygulamasındaki Temel Ağ Mimarisi

Production seviyesinde AI uygulaması çoğu zaman yalnızca frontend ve LLM API’den oluşmaz. Arada backend, API Gateway, orchestration, cache, queue ve observability katmanları bulunur. Her katmanın görevi açık biçimde tanımlanmalıdır. Gereksiz katmanlar latency oluşturabilir ancak gerekli kontrol noktalarını atlamak güvenlik ve operasyon sorunlarına yol açar. Kurumsal AI client-server mimarisi ve API entegrasyon hizmeti planlanırken data flow ilk olarak diyagram üzerinde gösterilmelidir.

Frontend / Client

Frontend kullanıcı girdisini alır ve backend’e gönderir. Authentication token gerekli olduğunda güvenli yöntemle eklenir. Streaming yanıt incremental olarak ekranda gösterilir. Stop ve retry gibi kontroller istemci tarafında bulunabilir. Gizli provider anahtarları frontend paketine dahil edilmemelidir.

Backend / Application Server

Backend iş kurallarının ana merkezidir. Kullanıcı yetkilerini doğrular ve provider çağrısını hazırlar. Prompt veya context burada birleştirilebilir. Request ID ve trace bilgisi yine backend’de oluşturulabilir. Client disconnect olduğunda upstream isteği iptal edecek mekanizma burada bulunmalıdır.

API Gateway

API Gateway ortak erişim kontrol noktasıdır. Authentication, rate limiting ve routing görevleri burada uygulanabilir. Büyük organizasyonlarda tenant bazlı quota yönetimini kolaylaştırır. Circuit breaker ile sorunlu upstream bağlantıları geçici olarak durdurulabilir. Request ve response dönüşümü de merkezi yapılabilir.

AI Orchestration Layer

Orchestration katmanı model, RAG ve tool akışını yönetir. Kullanıcı mesajı için uygun provider seçilebilir. Retrieval sonuçları prompt’a eklenebilir. Tool çağrıları burada yürütülebilir. Bu katman modelin doğrudan iş sistemlerine sınırsız erişmesini engelleyen önemli kontrol noktasıdır.

LLM Provider veya Model Server

Model sunucusu gerçek inference işlemini gerçekleştirir. Kurum içi vLLM benzeri servis veya harici API kullanılabilir. Streaming destekleniyorsa token parçaları upstream bağlantı üzerinden backend’e gelir. Model queue süresi TTFT değerini etkiler. Health check ve timeout politikası provider bazında tanımlanmalıdır.

Database

Database kullanıcı, conversation ve uygulama state bilgisini saklayabilir. Her token geldiğinde ayrı database yazımı yapmak performansı düşürebilir. Mesaj state’i kontrollü aralıklarla güncellenebilir. Transaction davranışı partial response senaryosuna göre tasarlanmalıdır. Hassas veriler şifreleme ve erişim politikasıyla korunmalıdır.

Vector Database

Vector database RAG senaryolarında benzerlik araması yapar. Retrieval latency toplam AI gecikmesine eklenir. Metadata filter kullanıcı yetkisini uygulamak için önemlidir. Index performansı ayrı gözlemlenmelidir. Retrieval sonucu model context oluşturulmadan önce authorization kontrolünden geçmelidir.

Cache

Cache sık kullanılan veriyi hızlı biçimde sunar. Session state veya rate limit counter Redis benzeri bir sistemde tutulabilir. Semantic cache AI maliyetini azaltabilir. Kullanıcıya özel verilerde cache izolasyonu zorunludur. TTL ve invalidation politikası açıkça belirlenmelidir.

Queue

Queue uzun süren asenkron işleri yönetir. Büyük doküman analizi gibi görevler HTTP bağlantısını dakikalarca açık tutmak yerine job olarak çalıştırılabilir. Worker bağımsız ölçeklenebilir. Kullanıcı Job ID üzerinden sonucu takip edebilir. Başarısız mesajlar Dead Letter Queue içine alınabilir.

Observability Katmanı

Observability request’in tüm katmanlardaki yolculuğunu görünür hale getirir. Distributed trace backend, retrieval ve provider sürelerini ayırabilir. Active connection ve TTFT gibi metrikler izlenmelidir. Hassas prompt içeriği loglara kontrolsüz yazılmamalıdır. Trace ID kullanıcı desteğinde hızlı teşhis sağlar.

AI İsteğinin Uçtan Uca Veri Akışı

Kullanıcının gönder butonuna basmasıyla başlayan süreç birçok katmandan geçer. Client-side validation yalnızca ilk kontroldür ve sunucu tarafı doğrulamasının yerini alamaz. HTTPS isteği backend’e ulaştığında kimlik ve rate limit kontrol edilir. Context hazırlandıktan sonra upstream model çağrısı yapılır. Streaming yanıt başladığında istemciye token, citation ve kullanım gibi farklı typed event’ler gönderilebilir.

Kullanıcının Mesaj Göndermesi

Kullanıcı chat alanına mesajını yazar. Frontend mesajı request payload içine dönüştürür. Conversation ID varsa istekle birlikte gönderilebilir. Kullanıcı tekrar gönder butonuna basarsa duplicate request oluşmaması için UI kontrolü uygulanabilir. Request sunucuya gönderildiğinde local optimistic state oluşturulabilir.

Client-Side Validation

Client mesaj uzunluğunu ve gerekli alanları kontrol edebilir. Dosya boyutu sınırı kullanıcıya erken gösterilebilir. Zararlı girdiye karşı güvenlik yalnızca frontend’e bırakılmamalıdır. Client validation kolayca bypass edilebilir. Backend aynı kuralları bağımsız olarak yeniden uygulamalıdır.

HTTPS İsteğinin Backend'e Ulaşması

Tarayıcı önce DNS çözümlemesi yapabilir. Ardından TCP veya QUIC bağlantısı oluşturulur. TLS handshake tamamlandığında şifreli kanal kurulur. Request CDN, WAF ve Gateway üzerinden backend’e ulaşabilir. Connection reuse bu adımların her istekte yeniden yapılmasını azaltır.

Authentication ve Authorization

Authentication kullanıcının kimliğini doğrular. Authorization hangi modele veya conversation’a erişebileceğini belirler. JWT veya session cookie kullanılabilir. Kullanıcı identity bilgisi backend tarafından güvenilir kaynaktan alınmalıdır. Frontend’in gönderdiği user ID tek başına authorization için kullanılmamalıdır.

Rate Limiting

Rate limit sistem kaynaklarının kötüye kullanılmasını önler. Kullanıcı ve tenant bazlı limit uygulanabilir. Uzun stream’lerde concurrent connection limiti özellikle önemlidir. Token bazlı quota AI maliyetiyle daha iyi ilişki kurar. Limit aşıldığında doğru 429 yanıtı ve Retry-After bilgisi döndürülebilir.

Prompt/Context Oluşturma

Backend kullanıcı mesajını system instruction ve conversation history ile birleştirir. RAG varsa ilgili dokümanlar retrieval ile alınır. Context token sınırı aşmamalıdır. Hassas bilgiler gereksiz yere modele eklenmemelidir. Prompt version observability metadata içinde saklanabilir.

AI Provider'a Upstream Request

Backend provider’a ayrı HTTP bağlantısıyla request gönderir. Provider için connection pooling kullanılmalıdır. Timeout değerleri normal database request’lerinden daha uzun olabilir. Streaming isteniyorsa upstream response stream olarak açılır. Provider request ID loglarda saklanabilir.

Model Inference

Model prompt tokenlarını işler. Queue yoğunluğu varsa inference başlamadan bekleme oluşabilir. İlk token üretildiğinde TTFT ölçümü tamamlanır. Ardından tokenlar belirli hızla oluşturulur. Model hızı donanım, batch ve context uzunluğundan etkilenir.

Response Streaming

Backend provider’dan gelen parçaları istemciye aktarır. Her token yerine küçük chunk kullanmak network overhead’i azaltabilir. Typed event formatı text ve tool event’lerini ayırır. Kullanıcı bağlantıyı kapatırsa stream hemen durdurulmalıdır. Upstream request iptal edilerek gereksiz model çalışması önlenir.

Frontend Rendering

Frontend stream parçalarını incremental olarak işler. Markdown içerik parça parça render edilir. Eksik code block sırasında UI bozulmamalıdır. Çok sık DOM update performansı düşürebilir. Render işlemi token buffering ile optimize edilebilir.

Logging ve Metrik Toplama

Request tamamlandığında latency ve usage bilgileri kaydedilebilir. TTFT, completion rate ve token count önemli metriklerdir. User prompt’un tamamını loglamak her zaman gerekli değildir. PII redaction uygulanabilir. Trace ID ile frontend ve backend olayları ilişkilendirilebilir.

Frontend Neden AI Provider'a Doğrudan Bağlanmamalı?

Frontend’in doğrudan LLM provider’a bağlanması küçük bir demo için kolay görünür ancak production güvenliği açısından ciddi risk taşır. Provider API key kullanıcıya teslim edilen JavaScript bundle veya network request içinde görünür hale gelebilir. Kullanıcı bazlı authorization ve cost control uygulamak zorlaşır. Backend relay yaklaşımı provider erişimini merkezi ve denetlenebilir hale getirir. Ayrıca provider değişikliğinde frontend uygulamasının yeniden yazılmasını engeller.

API Key Sızıntısı

Browser içindeki secret gerçek anlamda gizli değildir. Kullanıcı developer tools ile key’i görebilir. Obfuscation bu sorunu çözmez. Sızan anahtar üçüncü kişiler tarafından kullanılabilir. Provider secret yalnızca backend veya güvenli secret manager üzerinde tutulmalıdır.

Kullanıcı Bazlı Yetkilendirme Eksikliği

Provider çoğu zaman yalnızca application key’i görür. Gerçek kullanıcı identity bilgisi provider tarafında güvenilir authorization sağlamaz. Backend kullanıcının yetkisini kontrol etmelidir. Farklı tenant’ların model erişimleri ayrı olabilir. Bu politika frontend’e bırakılamaz.

Rate Limit Kontrolünün Kaybedilmesi

Doğrudan bağlantıda merkezi rate limit uygulamak zordur. Kullanıcı API isteğini manuel olarak tekrarlayabilir. Token tüketimi hızla artabilir. Backend quota ve concurrency kontrolü sağlar. Abuse detection bu noktada daha güvenilir çalışır.

Prompt ve System Instruction'ların Açığa Çıkması

Frontend tarafındaki system prompt kullanıcı tarafından görülebilir. Bu prompt içinde gizli bilgi bulunmaması zaten gerekir. Yine de uygulama iş mantığı ve policy detayları istemciye açılmamalıdır. Backend prompt assembly görevini üstlenebilir. Böylece prompt version ve feature flag merkezi yönetilir.

Provider Bağımlılığı

Frontend provider-specific endpoint kullanırsa migration maliyeti yükselir. Request ve stream formatları uygulama koduna yayılır. Backend ortak API contract sunabilir. Provider değişikliği yalnızca backend adapter üzerinde yapılabilir. Multi-provider routing bu sayede kolaylaşır.

Cost Abuse Riski

Provider key’inin kötüye kullanılması ciddi maliyet üretebilir. Attack script binlerce request gönderebilir. Backend cost budget ve quota uygular. User ve tenant bazında kullanım raporlanabilir. Şüpheli kullanım otomatik olarak engellenebilir.

Backend Relay / Proxy Yaklaşımı

Backend client ile provider arasında güvenli relay görevi görür. Authentication ve rate limit burada uygulanır. Provider stream’i kullanıcıya geçirilebilir. Kullanıcı disconnect olursa upstream request iptal edilir. Bu model kurumsal AI uygulamalarında güçlü bir varsayılan yaklaşımdır.

Backend-for-Frontend (BFF) ile AI İletişimi

BFF, belirli bir istemci türünün ihtiyaçlarına göre tasarlanmış backend katmanıdır. Web ve mobil istemcilerin farklı payload veya streaming ihtiyaçları varsa ayrı BFF servisleri kullanılabilir. AI provider bağlantısı bu katmanda gizlenebilir. Request normalization sayesinde istemci model detaylarından bağımsız hale gelir. BFF özellikle kullanıcı kimliği, stream relay ve cost tracking işlemlerini tek noktada toplamak için faydalıdır.

BFF Nedir?

BFF belirli frontend uygulamasına özel API sunar. Genel backend servisleriyle istemci arasında adaptasyon katmanı görevi görür. Mobile ve web farklı ihtiyaçlara sahip olabilir. AI çağrıları ortak orchestration servisine yönlendirilebilir. BFF business logic’i gereksiz yere çoğaltmamalıdır.

API Anahtarlarını Gizlemek

Provider key BFF tarafında secret manager üzerinden alınabilir. İstemci bu anahtarı hiçbir zaman görmez. Key rotation frontend release gerektirmez. Yetki yalnızca ilgili provider endpoint’leriyle sınırlandırılabilir. Secret loglara yazılmamalıdır.

Request Normalization

Farklı client sürümleri farklı request şekilleri gönderebilir. BFF bunları ortak internal contract’a dönüştürür. Provider-specific parametreler client’tan gizlenir. Bu yaklaşım backward compatibility sağlar. API schema versioning yine açık biçimde yönetilmelidir.

Provider Abstraction

BFF veya orchestration katmanı farklı provider’ları ortak arayüzle sunabilir. Uygulama model değişikliğini fark etmez. Streaming event formatı normalize edilebilir. Provider-specific hata kodları ortak error modeline dönüştürülebilir. Fallback implementation daha kolay hale gelir.

Authentication

BFF kullanıcı session veya access token bilgisini doğrular. Client tarafından gönderilen identity claim güvenilir issuer üzerinden doğrulanmalıdır. Kullanıcı role ve tenant bilgisi downstream’e aktarılabilir. Expired token stream başlamadan reddedilmelidir. Uzun stream sırasında token süresi politikası açık biçimde tanımlanmalıdır.

Rate Limiting

BFF kullanıcı bazlı request limiti uygulayabilir. Concurrent stream sayısı ayrıca kontrol edilebilir. Token budget uygulama maliyetini korur. Abuse pattern tespit edildiğinde kullanıcı geçici olarak sınırlandırılabilir. Rate limit state ortak Redis katmanında tutulabilir.

Logging

BFF request ID ve user metadata kaydedebilir. Ham prompt logging default olmamalıdır. Error ve latency logları operasyon için yeterli olabilir. Trace context downstream servislerine aktarılmalıdır. Log retention veri politikasına uygun olmalıdır.

Streaming Relay

BFF provider stream’ini client’a aktarabilir. Buffering minimum tutulmalıdır. Typed event normalization burada uygulanabilir. Client disconnect sinyali provider cancellation’a dönüştürülmelidir. Relay sırasında memory buffer sınırı bulunmalıdır.

Cost Tracking

Provider usage bilgisi request sonunda kaydedilebilir. User, tenant ve feature bazında maliyet raporu üretilebilir. Cached request farklı maliyet modeliyle işaretlenebilir. Retry sonucu duplicate billing kontrol edilmelidir. Cost metric product analytics ile birlikte kullanılabilir.

AI İletişiminde Hangi Protokol Kullanılmalı?

AI API entegrasyonunda REST WebSocket ve gRPC karşılaştırması yapılırken tek bir protokolün her senaryoya uygun olmadığı kabul edilmelidir. Kısa request-response işlemleri için REST oldukça pratiktir. Tek yönlü metin streaming için SSE genellikle yeterlidir. Gerçek zamanlı çift yönlü ses ve kontrol trafiğinde WebSocket veya WebRTC daha uygun olabilir. Servisler arası yüksek performans iletişiminde gRPC güçlü bir seçenektir.

REST / HTTP

REST basit request-response işlemleri için kullanışlıdır. JSON payload geniş araç desteğine sahiptir. Authentication ve gateway entegrasyonu kolaydır. Embedding ve classification gibi kısa işlemler için uygundur. Uzun token stream senaryosunda tek parça JSON kullanıcıyı gereksiz bekletebilir.

Server-Sent Events (SSE)

SSE sunucudan istemciye tek yönlü event akışı sağlar. Metin tabanlı LLM streaming için güçlü bir seçenektir. HTTP altyapısıyla uyumu genellikle yüksektir. Reconnection ve event ID mekanizması desteklenebilir. Client’tan sunucuya sürekli veri gerekiyorsa tek başına yeterli değildir.

WebSocket

WebSocket tam çift yönlü kalıcı bağlantı oluşturur. Client ve server istediği anda mesaj gönderebilir. Realtime agent ve voice uygulamalarında değerlidir. Connection state yönetimi SSE’ye göre daha fazla operasyon ister. Load balancer ve proxy upgrade desteği kontrol edilmelidir.

HTTP Streaming

HTTP response body parça parça gönderilebilir. Fetch ve ReadableStream ile tarayıcı tarafında işlenebilir. Özel SSE formatı kullanmak zorunlu değildir. Binary veya özel chunk formatları da kullanılabilir. Reconnection ve event semantics uygulama tarafından ayrıca tasarlanmalıdır.

gRPC

gRPC özellikle backend servisleri arasında güçlü bir seçenektir. HTTP/2 ve protobuf kullanır. Unary ve streaming çağrı modellerini destekler. Browser entegrasyonu doğrudan REST kadar basit olmayabilir. Internal model gateway ve mikroservis iletişiminde yüksek verim sağlayabilir.

WebRTC

WebRTC düşük latency media iletişimi için geliştirilmiştir. Sesli AI uygulamalarında önemli avantaj sağlar. NAT traversal için ICE, STUN ve TURN kullanabilir. Media stream gerçek zamanlı iletilir. Kurulumu metin tabanlı chat uygulamasına göre daha fazla ağ bilgisi gerektirir.

Webhook

Webhook uzun süren asenkron işin sonucunu başka sunucuya bildirmek için uygundur. Client bağlantısının açık kalmasına gerek yoktur. Callback endpoint güvenli biçimde authenticate edilmelidir. Retry ve signature verification uygulanmalıdır. Browser istemcilerine doğrudan webhook gönderilmez.

Message Queue

Queue servisler arasında asenkron iletişim sağlar. Büyük batch veya doküman işleme görevlerinde faydalıdır. Producer ve worker birbirinden bağımsız ölçeklenir. Retry ve dead letter mekanizması uygulanabilir. Kullanıcıya sonucu bildirmek için status endpoint veya event kanalı gerekir.

Protokol Seçim Karar Ağacı

Kısa işlem varsa önce REST düşünülmelidir. Sunucudan client’a token akışı gerekiyorsa SSE güçlü adaydır. Çift yönlü sürekli mesaj gerekiyorsa WebSocket değerlendirilmelidir. Gerçek zamanlı ses için WebRTC öne çıkar. Internal servis iletişiminde schema ve performans önemliyse gRPC düşünülebilir.

REST API AI Uygulamalarında Ne Zaman Kullanılır?

REST API birçok AI görevi için halen en basit ve güvenilir çözümdür. Her işlem streaming gerektirmez. Classification, embedding veya kısa structured extraction gibi görevlerde tek request ve tek response yeterlidir. REST altyapısının proxy, observability ve security desteği olgundur. Streaming yalnızca gerçek kullanıcı faydası sağladığı yerde eklenmelidir.

Tek Seferlik Request–Response

Kısa sürede tamamlanan işlem için REST uygundur. Client bir JSON payload gönderir. Server sonucu tek response ile döndürür. Hata yönetimi standart HTTP status kodlarıyla yapılabilir. Retry davranışı daha kolaydır.

Classification

Sınıflandırma işlemleri genellikle kısa çıktı üretir. Streaming kullanmak gereksizdir. Model sonucu tek JSON olarak döndürülebilir. Schema validation kolay uygulanır. Batch endpoint yüksek hacimde verimli olabilir.

Embedding

Embedding işlemi token generation stream’i üretmez. Input gönderilir ve vector sonucu alınır. REST bu kullanım için basittir. Batch embedding ile network overhead azaltılabilir. Büyük dataset işlemleri queue üzerinden asenkron çalıştırılabilir.

Moderation

Moderation çoğu zaman kısa classification sonucudur. Request-response modeli yeterlidir. Kritik path üzerinde olduğu için latency düşük tutulmalıdır. Timeout ana model çağrısından daha kısa olabilir. Failure policy fail-open veya fail-closed olarak risk seviyesine göre belirlenmelidir.

Structured Data Extraction

Belgeden alan çıkarma işlemi JSON sonuç üretebilir. Kısa işlemde REST yeterlidir. Çok büyük belgelerde asenkron job daha iyi olabilir. Schema validation sunucu tarafında yapılmalıdır. Invalid output kullanıcıya ham olarak gönderilmemelidir.

Kısa LLM Yanıtları

Yanıt birkaç token ise streaming anlamlı fayda sağlamayabilir. REST implementation daha basit olur. Client tarafında state yönetimi azalır. Proxy ve CDN davranışı öngörülebilir olur. Kullanım büyüdüğünde gerekirse streaming endpoint ayrıca eklenebilir.

REST'in Avantajları

REST yaygın ve iyi anlaşılmış bir protokol modelidir. Tool ve monitoring desteği güçlüdür. Authentication standartları kolay uygulanır. Load balancer ve gateway entegrasyonu basittir. Debug browser ve curl üzerinden rahat yapılabilir.

REST'in Uzun AI İşlerindeki Sınırlamaları

Uzun inference sırasında kullanıcı boş ekran görebilir. Proxy timeout isteği sonlandırabilir. Retry duplicate işlem üretebilir. Büyük response client memory kullanımını artırabilir. Streaming veya asenkron job modeli bu sorunları azaltabilir.

AI Yanıtlarında Streaming Nedir?

Streaming model yanıtının tamamlanmasını beklemek yerine üretildikçe istemciye aktarılmasıdır. Chat uygulamalarında kullanıcı ilk kelimeleri daha erken görür. Bu durum toplam inference süresini her zaman azaltmaz ancak algılanan gecikmeyi düşürür. TTFT kullanıcı deneyimi için temel metriktir. Streaming tasarımında event formatı, cancellation ve hata yönetimi baştan düşünülmelidir.

Streaming Olmadan Response Akışı

Server modelin tüm yanıtını bekler. Tam metin hazır olduğunda HTTP response gönderilir. Kullanıcı bu süre boyunca içerik görmez. Uzun cevaplarda bekleme hissi büyür. Implementation ise streaming’e göre daha basittir.

Token-by-Token Streaming

Model token ürettikçe backend parça alır. Bu parçalar client’a aktarılır. Her tokenı tek paket yapmak gerekli değildir. Küçük chunk’lar daha verimli olabilir. Client parçaları birleştirerek metni oluşturur.

Streaming'in Kullanıcı Deneyimine Etkisi

Kullanıcı ilk cevabı daha erken görür. Uzun metinler daha akıcı hissedilir. Stop button gerçek anlam kazanır. Partial result kullanıcının bekleme süresini daha kabul edilebilir hale getirir. Çok küçük chunk’ların titrek render edilmesi ise UX’i bozabilir.

Time to First Token (TTFT)

TTFT request başlangıcı ile ilk üretilen token arasındaki süredir. DNS ve gateway gecikmesi bu değere katkıda bulunabilir. Retrieval ve model queue süresi de etkiler. P95 TTFT production için izlenmelidir. Model değişimlerinde regression hızlı biçimde görülebilir.

Time to Last Token

Time to Last Token tüm yanıtın tamamlanma süresini gösterir. Response uzunluğu bu metriği etkiler. Kullanıcı ilk tokenı hızlı görse bile toplam süre uzun olabilir. Token generation speed ayrıca ölçülmelidir. Ürün gereksinimine göre maksimum cevap uzunluğu sınırlandırılabilir.

Streaming'in Toplam Inference Süresini Değiştirip Değiştirmediği

Streaming çoğu durumda modelin toplam hesaplama süresini azaltmaz. Fark yanıt parçalarının beklemeden kullanıcıya aktarılmasıdır. Bazı buffering ve scheduling farkları küçük değişiklik yaratabilir. Asıl kazanç algılanan latency üzerindedir. Bu nedenle TTFT ile total generation ayrı izlenmelidir.

Server-Sent Events (SSE) Nedir?

SSE HTTP üzerinden sunucudan istemciye event akışı göndermek için kullanılan basit bir mekanizmadır. LLM chat ve copilot uygulamalarında tek yönlü streaming ihtiyacını iyi karşılar. Response content type olarak text/event-stream kullanılır. Event satırları belirli formatta gönderilir. Reconnection ve event ID desteği bağlantı kopmalarında güvenilirlik sağlayabilir.

SSE Nasıl Çalışır?

Client HTTP bağlantısını açar. Server response’u kapatmak yerine açık tutar. Event verileri satır bazlı formatla gönderilir. Client event geldikçe işler. Stream tamamlandığında bağlantı kapatılabilir.

text/event-stream

SSE response content type text/event-stream olmalıdır. Proxy bu response’u normal JSON gibi buffer etmemelidir. Cache çoğu durumda devre dışı bırakılır. Encoding genellikle UTF-8 olur. Header’lar stream başlamadan doğru ayarlanmalıdır.

SSE Event Formatı

SSE event’leri basit metin satırlarından oluşur. event alanı event tipini belirtebilir. data alanı payload taşır. id alanı reconnection için kullanılabilir. retry client’a yeniden bağlanma süresini önerebilir.

event

event satırı event türünü tanımlar. Örneğin token veya error kullanılabilir. Client farklı event tiplerini ayrı handler ile işleyebilir. Typed event yaklaşımı stream contract’ını daha anlaşılır yapar. Event adı versioning politikasına dahil edilmelidir.

data

data gerçek payload bilgisini taşır. JSON string kullanılması yaygındır. Tek event birden fazla data satırı içerebilir. Client parse hatalarını güvenli biçimde yönetmelidir. Hassas veri gereksiz metadata ile gönderilmemelidir.

id

id event’in sıra veya cursor bilgisini taşıyabilir. Client reconnect olduğunda son event ID’yi bildirebilir. Server kaldığı yerden devam etme kararı verebilir. Her sistem gerçek resume desteği sunmak zorunda değildir. Duplicate event korumasında bu alan faydalıdır.

retry

retry yeniden bağlantı öncesi bekleme süresini belirtebilir. Çok kısa süre reconnect storm oluşturabilir. Çok uzun süre kullanıcı deneyimini bozabilir. Exponential backoff client tarafında ayrıca uygulanabilir. Network durumuna göre dinamik davranış düşünülebilir.

EventSource

EventSource browser’ın native SSE API’sidir. GET bağlantıları için kullanımı kolaydır. Automatic reconnection desteği vardır. Custom request body ihtiyacında sınırlamalar oluşabilir. Chat API’lerinde POST gerektiğinde fetch streaming daha esnek olabilir.

Fetch + ReadableStream

Fetch API POST request ile stream almayı mümkün kılar. ReadableStream chunk’ları client tarafında işler. Custom authentication header eklenebilir. SSE formatı manuel parse edilebilir. AbortController ile kullanıcı stop işlemi kolay uygulanır.

POST Request ile SSE

Klasik EventSource GET odaklıdır. Chat isteği genellikle POST body gerektirir. Fetch kullanılarak text/event-stream response okunabilir. Reconnection mekanizması bu durumda client tarafından tasarlanır. Idempotency key duplicate generation riskini azaltır.

SSE Reconnection

Mobil ağlarda bağlantı sık kopabilir. Client tekrar bağlanmayı deneyebilir. Aynı generation’ın yeniden başlamaması gerekir. Request state server tarafında tutulabilir. Resume desteklenmiyorsa kullanıcıya kontrollü retry sunulabilir.

Last-Event-ID

Last-Event-ID client’ın gördüğü son event’i belirtir. Server sonraki event’ten devam edebilir. Bunun için generation output buffer veya durable event log gerekir. Her tokenı uzun süre saklamak maliyetlidir. Resume stratejisi ürün gereksinimine göre seçilmelidir.

Keep-Alive

Uzun sessiz dönemlerde proxy bağlantıyı idle kabul edebilir. Periyodik keep-alive yorum veya event gönderilebilir. Bu veri kullanıcı ekranında gösterilmez. Timeout değerleri yine doğru yapılandırılmalıdır. Gereksiz çok sık heartbeat network overhead oluşturur.

WebSocket Nedir?

WebSocket istemci ve sunucu arasında kalıcı çift yönlü bağlantı sağlayan protokoldür. HTTP ile başlayan bağlantı upgrade işlemi sonrasında WebSocket kanalına dönüşür. Tarafların her ikisi de istediği anda mesaj gönderebilir. Voice AI, realtime agent ve collaborative uygulamalar için bu yapı değerlidir. Buna karşılık connection state ve scaling yönetimi SSE’ye göre daha fazla operasyon gerektirir.

HTTP Upgrade Handshake

WebSocket bağlantısı ilk olarak HTTP request ile başlar. Client upgrade header gönderir. Server kabul ederse protokol değişir. Reverse proxy bu header’ları doğru aktarmalıdır. Yanlış configuration localhost ile production arasında farklı sonuç oluşturabilir.

Full-Duplex İletişim

Full-duplex her iki tarafın aynı anda veri gönderebilmesini sağlar. Kullanıcı model konuşurken yeni audio chunk gönderebilir. Server tool event veya partial result yollayabilir. Bu yapı voice AI için güçlüdür. Basit chat streaming için her zaman gerekli değildir.

Text Frame

Text frame UTF-8 veri taşır. JSON event formatı sık kullanılır. Message type payload içinde belirtilebilir. Büyük JSON frame’leri sınırlandırılmalıdır. Schema validation server ve client tarafında yapılmalıdır.

Binary Frame

Binary frame audio veya başka ikili veri için uygundur. Base64 overhead’ini azaltabilir. Voice streaming performansı iyileşebilir. Frame boyutu kontrol edilmelidir. Client ve server codec formatında anlaşmalıdır.

Ping/Pong

Ping ve pong bağlantının canlı olup olmadığını kontrol eder. Network cihazları idle bağlantıyı kapatabilir. Periyodik ping bunun tespitini kolaylaştırır. Timeout sonrası bağlantı temizlenmelidir. Zombie connection resource tüketmemelidir.

Heartbeat

Uygulama seviyesinde heartbeat mesajı da kullanılabilir. Client session state bilgisi güncellenebilir. Missed heartbeat bağlantı problemi gösterebilir. Çok sık heartbeat ölçeklemede gereksiz trafik oluşturur. Mobil battery tüketimi de dikkate alınmalıdır.

Connection State Yönetimi

WebSocket uzun yaşayan connection state oluşturur. Hangi user ve conversation’a ait olduğu bilinmelidir. Reconnect durumunda eski state temizlenmelidir. Shared Redis gibi sistemler multi-instance backend’lerde kullanılabilir. State ownership karmaşıklaşmadan önce mimari basit tutulmalıdır.

Reconnection

Mobil veya Wi-Fi değişiminde WebSocket bağlantısı kopabilir. Client exponential backoff ile tekrar bağlanabilir. Session ID gönderilerek önceki state geri alınabilir. Duplicate message kontrolü uygulanmalıdır. Reconnect sırasında kullanıcıya durum gösterilmelidir.

Session Affinity

State belirli backend instance üzerinde tutuluyorsa sticky session gerekebilir. Bu durum load balancing esnekliğini azaltır. Paylaşılan state kullanmak daha yatay ölçeklenebilir olabilir. Connection zaten açık kaldığı sürece aynı instance üzerinde devam eder. Reconnect sonrası hangi node’a gidileceği ayrıca önemlidir.

SSE mi WebSocket mı?

SSE ve WebSocket seçimi ihtiyaç duyulan veri yönüne göre yapılmalıdır. Yalnızca server’dan client’a token akışı varsa SSE genellikle daha basit ve yeterlidir. Client’ın generation sırasında sürekli veri göndermesi gerekiyorsa WebSocket güçlü bir seçenektir. Voice AI ve realtime agent sistemleri çift yönlü bağlantıdan faydalanır. Operasyonel sadelik önemliyse gereksiz WebSocket kullanımından kaçınılmalıdır.

Tek Yönlü ve Çift Yönlü İletişim

SSE esas olarak server-to-client event akışı sunar. Client yeni request için normal HTTP kullanabilir. WebSocket iki yönlü sürekli mesajlaşmayı destekler. Chat completion çoğu zaman SSE ile çözülebilir. Realtime audio ise WebSocket veya WebRTC gerektirebilir.

Chat Uygulamaları

Standart chat uygulamasında kullanıcı mesajı bir kez gönderir. Model yanıtı server’dan client’a akar. SSE bu pattern ile iyi uyumludur. Stop button ayrı cancellation request veya abort ile çalışabilir. WebSocket zorunlu değildir.

Voice AI

Voice AI aynı anda audio upload ve response stream gerektirebilir. Kullanıcı konuşmaya devam ederken server veri gönderir. WebSocket çift yönlü yapı sağlar. WebRTC daha düşük media latency için değerlendirilebilir. Ağ ve codec gereksinimi uygulamaya göre test edilmelidir.

Realtime Agent

Realtime agent tool event ve kullanıcı müdahalesini sürekli yönetebilir. Client mid-stream control gönderebilir. WebSocket bu etkileşimi kolaylaştırır. Event schema güçlü biçimde versionlanmalıdır. Authorization her tool action’da yeniden kontrol edilmelidir.

Mid-Stream Control

Kullanıcı generation sırasında instruction değiştirmek isteyebilir. Pause veya cancel komutu gönderebilir. WebSocket bu komutları aynı bağlantıdan aktarabilir. SSE kullanılan sistemde ayrı HTTP control endpoint açılabilir. Basitlik ve gereksinim birlikte değerlendirilmelidir.

Proxy/CDN Uyumluluğu

SSE standart HTTP response üzerinden çalıştığı için birçok proxy ile uyumludur. Ancak buffering kapatılmalıdır. WebSocket için upgrade desteği gerekir. CDN timeout ve connection limitleri farklı olabilir. Production öncesi gerçek edge altyapısıyla test yapılmalıdır.

Serverless Uyumluluğu

Serverless platformların uzun connection limitleri farklılık gösterebilir. SSE bazı edge runtime’larda desteklenebilir. WebSocket ayrı managed service gerektirebilir. Execution timeout uzun model request’lerini sınırlayabilir. Platform seçimi protokol tasarımını etkiler.

Authentication

SSE normal HTTP header ve cookie mekanizmalarını kullanabilir. WebSocket handshake sırasında authentication yapılır. Token query string içinde taşınmamalıdır. Expired session reconnect sırasında yeniden kontrol edilmelidir. Uzun connection boyunca authorization değişikliği politikası belirlenmelidir.

Reconnection

SSE EventSource otomatik reconnect desteğine sahiptir. Fetch tabanlı SSE’de bu logic manuel olabilir. WebSocket reconnect uygulama seviyesinde tasarlanır. Duplicate mesaj ve state sorunları dikkate alınmalıdır. Resume mekanizması protokolden bağımsız ürün kararıdır.

Ölçeklenebilirlik

Her iki protokol de çok sayıda açık bağlantı oluşturabilir. Capacity planning yalnızca RPS üzerinden yapılamaz. File descriptor ve memory per connection izlenmelidir. WebSocket state daha fazla operasyon yükü yaratabilir. SSE stateless backend tasarımına daha kolay uyabilir.

Operasyonel Karmaşıklık

SSE metin streaming için daha basit bir model sunar. WebSocket connection lifecycle yönetimi gerektirir. Ping, reconnect ve state synchronization ek iş çıkarır. Gerçek fayda yoksa WebSocket seçmek gereksiz risk yaratır. Protokol kullanım senaryosuna göre seçilmelidir.

SSE Hangi AI Senaryoları İçin Daha Uygundur?

SSE özellikle server’ın uzun süre boyunca kullanıcıya event göndermesi gereken ancak client’ın aynı connection üzerinden sürekli veri göndermediği durumlarda uygundur. Metin tabanlı LLM uygulamaları bunun en belirgin örneğidir. Browser desteği ve HTTP altyapısıyla uyumu deployment sürecini kolaylaştırabilir. Typed event yaklaşımı yalnızca token değil citation ve tool progress gibi bilgiler de taşımayı mümkün kılar. Kurumsal chat ve copilot projelerinde ilk değerlendirilecek streaming seçeneklerinden biridir.

Chatbot

Kullanıcı mesajı POST ile gönderilebilir. Yanıt SSE stream olarak alınabilir. Tokenlar ekranda incremental gösterilir. Stop button request’i abort edebilir. Basit chat için WebSocket gereksiz olabilir.

AI Copilot

Copilot uzun önerileri parça parça gösterebilir. Citation ve progress event’leri ayrıca gönderilebilir. Client yeni komutlar için ayrı HTTP request kullanabilir. SSE deployment kolaylığı sağlar. Kullanıcı context değiştirirse mevcut request iptal edilmelidir.

Kod Asistanı

Kod generation token bazlı akıştan faydalanır. İlk satır kullanıcıya hızlı görünür. Partial code block dikkatli render edilmelidir. Syntax highlighting her token sonrası çalıştırılmamalıdır. SSE bu tek yönlü akışı yeterince karşılar.

Doküman Özetleme

Uzun özet generation birkaç saniye sürebilir. SSE kullanıcıya ilerleme hissi verir. Citation event’leri kaynak bölümlerini gösterebilir. Çok büyük doküman preprocessing asenkron job olabilir. Generation aşaması yine stream edilebilir.

RAG Yanıtları

RAG cevabı retrieval sonrası stream edilebilir. İlk event kaynak metadata’sı olabilir. Ardından token event’leri gelir. Citation’lar typed event olarak gönderilebilir. Kullanıcı yetkisi retrieval öncesi uygulanmalıdır.

Agent Event Streaming

Agent uzun işlemlerde progress event gönderebilir. Tool start ve tool result ayrı event olabilir. Kullanıcı yalnızca süreci izliyorsa SSE yeterlidir. Mid-stream intervention gerekiyorsa ayrı control endpoint kullanılabilir. Daha yoğun çift yönlü iletişimde WebSocket değerlendirilebilir.

WebSocket Hangi AI Senaryolarında Kullanılmalı?

WebSocket iki yönlü sürekli mesajlaşmanın gerçek bir gereksinim olduğu AI uygulamalarında öne çıkar. Voice AI bunun en yaygın örneklerinden biridir. Kullanıcı audio gönderirken sistem aynı anda transkripsiyon veya sesli yanıt aktarabilir. Realtime multi-agent sistemlerinde tool ve state event’leri her iki yönde hareket edebilir. Bu avantajlara rağmen basit text chat için WebSocket kullanmak zorunlu değildir.

Gerçek Zamanlı Sesli Asistan

Kullanıcı mikrofon verisini sürekli gönderir. Server transkripsiyon ve cevap parçaları üretir. Çift yönlü kanal gereklidir. WebSocket bu mesajları tek connection üzerinden taşıyabilir. Düşük media latency gerekiyorsa WebRTC ayrıca değerlendirilmelidir.

Audio Streaming

Audio binary frame halinde gönderilebilir. Chunk boyutu latency ve overhead dengesini etkiler. Codec formatı iki tarafça bilinmelidir. Backpressure uygulanmalıdır. Client çok hızlı veri üretirse server buffer büyümemelidir.

Canlı Transkripsiyon

Mikrofon sesi parça parça STT servisine iletilir. Partial transcript client’a geri gönderilir. Final transcript ayrı event olarak işaretlenebilir. Kullanıcı konuşmayı sürdürürken response devam eder. WebSocket full-duplex yapı sağlar.

Kullanıcının Generation Sırasında Veri Göndermesi

Kullanıcı model yanıt verirken ek talimat verebilir. Cancel veya interrupt mesajı gönderebilir. Aynı bağlantıda kontrol event’i taşınabilir. Server state transition açık biçimde yönetilmelidir. Duplicate control event güvenli şekilde ele alınmalıdır.

Realtime Multi-Agent Sistemleri

Birden fazla agent state event üretebilir. Kullanıcı belirli agent’a yönlendirme yapabilir. Çok sayıda event tipi oluşur. Typed protocol zorunlu hale gelir. Distributed trace her agent adımını ilişkilendirmelidir.

Ortak Çalışma Uygulamaları

Birden fazla kullanıcı aynı AI session üzerinde çalışabilir. State değişiklikleri anlık yayınlanabilir. Presence bilgisi WebSocket ile aktarılabilir. Conflict resolution ayrıca tasarlanmalıdır. AI event’leri collaborative state event’lerinden ayrılmalıdır.

WebRTC ile Gerçek Zamanlı AI İletişimi

WebRTC özellikle ses ve video gibi gerçek zamanlı medya akışları için tasarlanmıştır. Voice AI uygulamalarında çok düşük gecikme hedeflendiğinde WebSocket’e göre avantaj sağlayabilir. Network koşullarına göre adaptive media davranışı sunar. NAT traversal için ICE, STUN ve TURN mekanizmaları kullanılır. Buna karşılık deployment ve troubleshooting bilgisi daha fazla uzmanlık gerektirir.

WebRTC Nedir?

WebRTC gerçek zamanlı browser ve uygulama iletişimi sağlar. Audio ve video stream destekler. Data channel üzerinden veri de taşınabilir. Peer bağlantısı signaling süreci gerektirir. AI media gateway bu bağlantının server tarafını yönetebilir.

Voice AI'da Neden Kullanılır?

Voice uygulamasında yüzlerce milisaniye fark hissedilebilir. WebRTC düşük latency media transport için optimize edilmiştir. Paket kaybı ve jitter yönetimi daha gelişmiştir. Audio codec desteği hazır gelir. Barge-in deneyimi daha doğal hale getirilebilir.

MediaStream

MediaStream mikrofon veya kamera track’lerini temsil eder. Browser kullanıcı izni gerektirir. Audio track WebRTC connection üzerinden gönderilebilir. Mute ve device switching yönetilebilir. Gizlilik açısından medya yalnızca gerekli durumda açılmalıdır.

PeerConnection

RTCPeerConnection WebRTC bağlantısının temel API’sidir. Codec negotiation ve transport durumunu yönetir. Connection state değişimleri izlenmelidir. ICE candidate exchange signaling kanalından yapılır. Reconnect veya renegotiation durumları test edilmelidir.

ICE

ICE iki endpoint arasında uygun network yolunu bulmaya çalışır. Local ve public candidate seçenekleri değerlendirilir. Kurumsal firewall bağlantıyı etkileyebilir. TURN fallback önemli olabilir. ICE failure metric olarak izlenmelidir.

STUN ve TURN

STUN client’ın dış network adresini öğrenmesine yardımcı olur. TURN doğrudan bağlantı mümkün değilse relay görevi görür. TURN bandwidth maliyeti oluşturabilir. Kurumsal ağlarda relay kullanımı daha sık görülebilir. Kapasite planning media trafiğini hesaba katmalıdır.

Audio Latency

Audio latency network, codec ve processing katmanlarının toplamıdır. STT ve TTS süreleri de kullanıcı deneyimini etkiler. Jitter buffer fazla büyürse gecikme artar. P95 audio round-trip izlenmelidir. Kullanıcı interruption testi gerçek cihazlarda yapılmalıdır.

WebRTC vs WebSocket

WebSocket genel amaçlı mesaj kanalına uygundur. WebRTC media için daha optimize edilmiştir. Binary audio WebSocket ile de gönderilebilir. Düşük latency ve network adaptation öncelikliyse WebRTC güçlü adaydır. Mimari ekip uygulama gereksinimine göre karar vermelidir.

Voice AI'da Client-Server Veri Akışı

Voice AI akışında mikrofon verisi capture edilir, uygun chunk’lara ayrılır ve server’a iletilir. Speech-to-text sonucu LLM’e girer. Model yanıtı text-to-speech servisine aktarılır ve ses client’a stream edilir. Kullanıcı model konuşurken araya girdiğinde mevcut generation ve TTS mümkün olduğunca hızlı iptal edilmelidir. Bu zincirde her milisaniye toplam konuşma deneyimini etkiler.

Mikrofon Girdisi

Client mikrofon izni ister. Audio stream belirli sample rate ile yakalanır. Gereksiz yüksek kalite bandwidth tüketimini artırabilir. Browser veya native API kullanılabilir. Hassas audio verisi yalnızca gerekli endpoint’e gönderilmelidir.

Voice Activity Detection

VAD kullanıcının gerçekten konuşup konuşmadığını belirler. Sessiz audio paketlerinin gönderilmesini azaltabilir. Konuşmanın başlangıç ve bitişini daha hızlı tespit eder. Barge-in için önemli sinyal sağlar. Yanlış eşik kelimelerin kesilmesine neden olabilir.

Audio Chunking

Audio küçük zaman dilimlerine ayrılır. Çok büyük chunk latency artırır. Çok küçük chunk network overhead oluşturur. Codec ve transport birlikte optimize edilmelidir. Backpressure server yüküne göre uygulanabilir.

Speech-to-Text

STT audio chunk’larından partial transcript oluşturabilir. Final transcript kullanıcı cümlesi tamamlandığında işaretlenir. Partial sonuçlar UI’da gösterilebilir. LLM’in her partial kelime için çağrılması gereksizdir. Endpointing stratejisi konuşma deneyimini etkiler.

LLM

Transcript LLM’e prompt olarak gönderilir. Conversation state server tarafında bulunabilir. Model streaming text üretir. İlk token TTS pipeline’a erken verilebilir. Böylece kullanıcı yanıt sesini daha hızlı duyar.

Text-to-Speech

TTS model çıktısını sese dönüştürür. Streaming TTS ilk cümle tamamlanmadan audio üretebilir. Ses parçaları client’a aktarılır. Voice seçimi ve codec latency üzerinde etkili olabilir. Generation iptalinde TTS de hemen durdurulmalıdır.

Audio Streaming

Audio response client’a parça parça gönderilir. Playback buffer aşırı büyütülmemelidir. Network jitter küçük buffer ile dengelenir. Kullanıcı stop verdiğinde queue temizlenmelidir. Eski audio yeni response ile karışmamalıdır.

Kullanıcının Modeli Bölmesi

Doğal konuşmada kullanıcı karşı tarafın sözünü kesebilir. AI sisteminin bunu desteklemesi gerekir. Yeni speech activity mevcut generation’ı durdurabilir. Client ve server state aynı anda güncellenmelidir. Eski audio chunk’ları playback queue’dan kaldırılmalıdır.

Barge-In

Barge-in kullanıcının model konuşurken araya girmesidir. VAD bu davranışı tespit edebilir. TTS playback hemen durdurulur. LLM generation iptal edilebilir. Yeni kullanıcı mesajı conversation state’e doğru sırada eklenmelidir.

Upstream Cancellation

Cancellation yalnızca client playback’i durdurmakla kalmamalıdır. Backend provider request’i de iptal etmelidir. STT veya TTS stream varsa onlar da kapanmalıdır. Kullanılmayan token maliyeti azalır. Usage kaydı partial completion olarak işaretlenebilir.

HTTP/1.1, HTTP/2 ve HTTP/3 AI Uygulamalarını Nasıl Etkiler?

HTTP sürümü AI uygulamasının model kalitesini değiştirmez ancak connection ve multiplexing davranışını etkileyebilir. HTTP/1.1 bağlantı başına sınırlı concurrency sunar. HTTP/2 tek bağlantı üzerinde birden fazla stream taşıyabilir. HTTP/3 QUIC üzerinde çalışır ve mobil ağ değişimlerinde avantaj sağlayabilir. Gerçek fayda altyapı ve istemci desteğiyle birlikte ölçülmelidir.

Persistent Connection

Persistent connection birden fazla request’in aynı bağlantıyı kullanmasını sağlar. Her istekte handshake yapılmaz. Latency azalabilir. Provider bağlantılarında özellikle faydalıdır. Idle timeout çok kısa olmamalıdır.

HTTP Keep-Alive

Keep-Alive TCP bağlantısının tekrar kullanılmasını sağlar. Backend-to-provider çağrılarında önemlidir. Connection pool bu davranışı yönetebilir. Çok uzun idle connection kaynak tüketebilir. Provider limitleri dikkate alınmalıdır.

Multiplexing

HTTP/2 bir bağlantı üzerinde birden fazla request stream taşır. Connection sayısı azalabilir. Head-of-line davranışı HTTP/1.1’e göre iyileşir. Backend servis iletişiminde fayda sağlayabilir. Uygulama seviyesinde provider concurrency yine sınırlanmalıdır.

Head-of-Line Blocking

HTTP/1.1’de aynı connection üzerindeki sıralı işlemler gecikme yaratabilir. HTTP/2 stream seviyesinde bu problemi azaltır. TCP packet loss yine tüm connection’ı etkileyebilir. HTTP/3 QUIC ile stream izolasyonunu iyileştirebilir. Mobil network testleri gerçek avantajı göstermelidir.

HTTP/2 Stream'leri

HTTP/2 stream bağımsız request-response kanallarıdır. Aynı TCP connection paylaşılır. gRPC bu altyapıyı kullanır. Çok sayıda internal request için verimlidir. Connection-level failure tüm stream’leri etkileyebilir.

QUIC ve HTTP/3

HTTP/3 QUIC transport kullanır. UDP üzerinde güvenilirlik ve encryption sağlar. Connection migration mobil network geçişlerinde faydalıdır. Packet loss etkisi stream bazında daha iyi izole edilir. Proxy ve firewall desteği kontrol edilmelidir.

Mobil Ağlarda HTTP/3 Avantajı

Mobil kullanıcı Wi-Fi ile 5G arasında geçiş yapabilir. QUIC connection migration bu değişimi daha iyi yönetebilir. Yeniden TCP handshake ihtiyacı azalabilir. Gerçek fayda carrier ve platform desteğine bağlıdır. Uygulama yine reconnect state tasarımına ihtiyaç duyar.

DNS, TCP ve TLS AI Latency'sini Nasıl Etkiler?

AI latency yalnızca model inference süresinden oluşmaz. DNS lookup, TCP handshake ve TLS negotiation ilk request süresine eklenir. Connection reuse bu maliyetleri sonraki çağrılarda azaltır. Backend ile provider arasında connection pooling kullanmak TTFT üzerinde ölçülebilir fark yaratabilir. Özellikle kısa model çağrılarında network setup süresi toplam gecikmenin önemli bölümünü oluşturabilir.

DNS Lookup

Client hostname’i IP adresine çözmek zorundadır. DNS cache tekrar sorguyu azaltabilir. Yavaş resolver request başlangıcını geciktirir. Multiple provider kullanımında her host ayrı lookup gerektirebilir. DNS failure ayrı metric olarak izlenmelidir.

TCP Handshake

TCP bağlantısı kurulmadan HTTP/1.1 veya HTTP/2 trafiği başlayamaz. Round-trip latency handshake süresini etkiler. Uzak provider’a bağlantı daha uzun sürebilir. Keep-alive bu işlemi tekrar etmekten kaçınır. SYN failure network sorunu gösterebilir.

TLS Handshake

TLS güvenli session anahtarını oluşturur. Certificate validation ve round-trip maliyeti vardır. Modern TLS sürümleri bu süreci optimize eder. Session resumption tekrar bağlantıda süreyi azaltabilir. Certificate problemi AI servisini tamamen erişilemez hale getirebilir.

Connection Reuse

Aynı connection birden fazla request için kullanılabilir. DNS ve handshake maliyetleri amorti edilir. Provider API çağrılarında büyük fayda sağlar. Pool doğru boyutlandırılmalıdır. Eski veya kapalı connection otomatik temizlenmelidir.

TLS Session Resumption

Session resumption yeni TLS bağlantısını daha hızlı kurabilir. Önceki session bilgisi tekrar kullanılır. Özellikle sık reconnect durumunda yararlıdır. Proxy katmanları davranışı etkileyebilir. Security policy ile uyumlu yapılandırılmalıdır.

Connection Pooling

Backend her AI request için yeni connection açmamalıdır. HTTP client shared pool kullanmalıdır. Pool provider başına ayrı yönetilebilir. Maximum connection concurrency ile uyumlu olmalıdır. Pool exhaustion request queue süresini artırabilir.

Connection Pooling Neden Önemlidir?

Connection pooling özellikle backend ile LLM provider arasındaki sık çağrılarda gereksiz handshake maliyetini azaltır. Her request için yeni TCP ve TLS bağlantısı açmak latency ve CPU maliyeti oluşturur. Pool doğru boyutlandırılmazsa yüksek trafikte bekleyen request sayısı artabilir. Çok büyük pool ise provider rate limit veya işletim sistemi kaynaklarını zorlayabilir. Bu nedenle connection sayısı load test sonucu üzerinden belirlenmelidir.

Her AI İsteğinde Yeni Bağlantı Açmanın Maliyeti

Yeni connection DNS, TCP ve TLS işlemi gerektirebilir. Bu süreç uzak provider’da onlarca veya yüzlerce milisaniye ekleyebilir. Socket kaynakları daha hızlı tüketilir. Server CPU yükü artabilir. Reuse daha verimli davranış sağlar.

HTTP Keep-Alive

Keep-alive mevcut connection’ın kullanılmasını sağlar. HTTP client library genellikle bunu destekler. Idle timeout provider ile uyumlu olmalıdır. Reset olmuş socket yeniden açılmalıdır. Connection reuse metric olarak izlenebilir.

Maximum Connection Sayısı

Pool sınırsız büyümemelidir. Her connection file descriptor ve memory tüketir. Provider concurrency limitleri vardır. Çok düşük limit request queue oluşturur. Değer load ve latency hedeflerine göre seçilmelidir.

Idle Connection

Kullanılmayan connection belirli süre pool’da kalabilir. Çok uzun idle süre gereksiz kaynak tutar. Çok kısa süre reuse avantajını azaltır. Provider connection timeout dikkate alınmalıdır. Health check veya retry stale connection sorununu yönetebilir.

Pool Exhaustion

Tüm pool connection’ları meşgulse yeni request bekler. Bu süre model latency sanılabilir. Pool wait metric ayrı ölçülmelidir. Concurrency artışı root cause olabilir. Limit kör şekilde yükseltilmeden downstream kapasitesi kontrol edilmelidir.

Provider Başına Ayrı Connection Pool

Farklı provider’ların network ve rate limit özellikleri değişir. Ayrı pool izolasyon sağlar. Sorunlu provider diğerinin connection kapasitesini tüketmez. Timeout değerleri farklı tutulabilir. Multi-provider gateway için bu yaklaşım faydalıdır.

AI Sistemlerinde Latency Nasıl Ölçülür?

AI performansı tek bir toplam süreyle ölçülmemelidir. DNS, connection, TLS, retrieval, queue ve model generation süreleri ayrı ayrıştırılmalıdır. TTFT kullanıcının ilk cevabı ne zaman gördüğünü gösterir. Inter-token latency akışın ne kadar akıcı olduğunu ölçer. Distributed tracing tüm bu aşamaları tek request altında ilişkilendirmeyi kolaylaştırır.

DNS Süresi

DNS lookup başlangıç ağ gecikmesini gösterir. Client ve backend tarafında farklı olabilir. Cache hit ve miss ayrı sonuç üretir. Çok yüksek değer resolver problemi gösterebilir. Provider hostname değişiklikleri izlenmelidir.

Connection Süresi

TCP veya QUIC connection kurulma süresi ölçülmelidir. Uzak region latency’yi artırabilir. Connection reuse olduğunda değer sıfıra yakın olabilir. Yeni connection oranı izlenebilir. Ani artış network sorunu gösterebilir.

TLS Süresi

TLS handshake latency ayrı ölçülebilir. Certificate validation veya proxy etkisi görülebilir. Session resumption fark yaratabilir. Expired certificate bağlantıyı tamamen engeller. TLS metric network observability içinde tutulmalıdır.

Backend Processing Time

Backend validation ve prompt hazırlama süresi bu metriktir. Ağ veya model latency’den ayrılmalıdır. Yavaş serialization veya database query burada görünür. P95 değer takip edilmelidir. Gereksiz synchronous işlemler stream başlamasını geciktirebilir.

Retrieval Latency

RAG vector search toplam TTFT’ye eklenir. Embedding generation süresi de dahil olabilir. Reranking ayrı span olarak ölçülmelidir. Çok yüksek top-k latency artırabilir. Retrieval quality ile performans birlikte değerlendirilmelidir.

Model Queue Time

Request model tarafından işlenmeden önce bekleyebilir. GPU saturation bu süreyi artırır. Provider bazen queue metric sağlamaz. TTFT artışı dolaylı sinyal olabilir. Self-hosted serving’de queue depth açıkça izlenmelidir.

Time to First Token

TTFT kullanıcı mesajı ile ilk token arasındaki süredir. Ağ, backend, retrieval ve model prefill sürelerini içerir. P50 ve P95 izlenmelidir. Cache hit durumunda önemli ölçüde düşebilir. Ürün deneyimi için ana SLI olabilir.

Inter-Token Latency

Inter-token latency ardışık tokenlar arasındaki süredir. Yüksek değer cevap akışını takılarak gösterir. GPU yükü veya provider throttling etkileyebilir. Client buffering metric’i yanlış yorumlamamalıdır. Ham provider timestamp ile client receive zamanı ayrıştırılabilir.

Total Generation Time

İlk token ile son token arasındaki üretim süresidir. Response uzunluğuna doğrudan bağlıdır. Tokens per second metriği daha karşılaştırılabilir olabilir. Stop token veya max token ayarları etkiler. Uzun cevap policy ile sınırlandırılabilir.

End-to-End Latency

Kullanıcının request başlatması ile final UI state arasındaki toplam süredir. Client rendering de bu değere dahildir. Server ölçümü tek başına yeterli değildir. Real user monitoring faydalı olabilir. Mobil ağlar desktop’tan farklı dağılım gösterebilir.

Latency Budget Nasıl Oluşturulur?

Latency budget toplam kullanıcı gecikmesini katmanlara paylaştırır. Böylece hangi servisin ne kadar süre kullanabileceği daha görünür hale gelir. Örneğin retrieval için yüzlerce milisaniye ayrılırken model TTFT için daha büyük pay bırakılabilir. P95 ve P99 hedefleri yalnızca ortalamaya göre daha gerçekçi sonuç verir. Budget sürekli ölçülmeli ve model veya network değişikliklerinde yeniden değerlendirilmelidir.

Client → Edge

Kullanıcı ile CDN veya edge arasındaki network süresidir. Coğrafi uzaklık etkiler. Mobil bağlantılar daha değişken olabilir. Geo routing süreyi azaltabilir. P95 değer region bazında izlenebilir.

Edge → Backend

Edge ile origin backend arasındaki network süresidir. Aynı region deployment düşük latency sağlar. Cross-region route maliyet ekler. WAF processing küçük süre ekleyebilir. Trace bu katmanı görünür hale getirmelidir.

Backend → Database

Conversation state veya kullanıcı bilgisi database’den alınabilir. Query latency düşük tutulmalıdır. AI model çağrısından önce gereksiz çok sorgu TTFT’yi uzatır. Connection pool kullanılmalıdır. N+1 query hatalarından kaçınılmalıdır.

Backend → LLM

Provider network süresi ayrı budget almalıdır. Aynı region private endpoint avantaj sağlayabilir. Connection reuse latency’yi düşürür. Upstream timeout budget’tan daha uzun olmamalıdır. Multi-provider routing network farkını dikkate alabilir.

Model TTFT

Model prefill ve queue süresi genellikle budget’ın büyük kısmını kullanır. Context uzunluğu etkiler. Daha küçük model daha hızlı olabilir. Cache ve prompt optimization fayda sağlayabilir. P95 hedefi model seçimine dahil edilmelidir.

Token Streaming

İlk token sonrası akış hızı kullanıcı deneyimini belirler. Çok küçük buffer network overhead oluşturur. Çok büyük buffer tokenları geciktirir. Flush stratejisi ölçülmelidir. Client render süresi de göz önünde bulundurulmalıdır.

Frontend Rendering

Client her chunk geldiğinde DOM günceller. Çok sık render düşük güçlü cihazlarda yavaşlama yaratabilir. Markdown parser pahalı olabilir. Frame bazlı batching kullanılabilir. UI latency network metric’lerinden ayrı izlenmelidir.

P50, P95 ve P99 Kullanımı

P50 tipik kullanıcı deneyimini gösterir. P95 kötü deneyim yaşayan önemli bir kullanıcı grubunu temsil eder. P99 nadir ama ciddi gecikmeleri görünür kılar. Yalnızca ortalama kullanmak tail problemlerini gizler. SLO hedefleri en az P95 üzerinden tanımlanmalıdır.

AI Streaming Event Protocol Nasıl Tasarlanmalı?

Streaming API yalnızca ham text parçaları göndermekten daha güçlü bir contract’a ihtiyaç duyar. Tool calling, citation, usage ve error gibi olaylar aynı stream içinde farklı anlam taşır. Typed event yaklaşımı client’ın her olayı güvenli biçimde işlemesini sağlar. Event schema versioning ileride format değişikliğini yönetir. Sequence number ve event ID duplicate veya sıralama sorunlarının çözümüne yardımcı olur.

Ham Token Göndermenin Problemleri

Ham string yalnızca basit text akışında yeterlidir. Tool call geldiğinde nasıl ayırt edileceği belirsizleşir. Error veya usage bilgisi ayrı format gerektirir. Client parser zamanla özel karakterlere bağımlı hale gelir. Typed protocol daha sürdürülebilir olur.

Typed Event Yaklaşımı

Her event açık bir type alanı taşır. Payload ilgili tipe göre schema kullanır. Client switch veya dispatcher ile işler. Yeni event türü backward compatible eklenebilir. Unknown event güvenli biçimde ignore edilebilir.

token

token event generation metninin bir parçasını taşır. Tek token olmak zorunda değildir. Sequence number eklenebilir. Client buffer’a ekler. Sensitive metadata bu event içine karıştırılmamalıdır.

message_start

message_start yeni assistant mesajının başladığını bildirir. Message ID bu event’te üretilebilir. Model veya metadata bilgisi eklenebilir. Client placeholder UI oluşturabilir. Aynı stream içinde birden fazla mesaj varsa ayrımı kolaylaştırır.

tool_call

tool_call modelin araç kullanmak istediğini bildirir. Tool adı ve argument parçaları taşınabilir. Client her zaman bu aracı çalıştırmamalıdır. Execution backend authorization katmanında yapılmalıdır. UI yalnızca progress gösterebilir.

tool_result

tool_result backend’in araç çalıştırma sonucunu bildirir. Hassas raw data client’a gönderilmemelidir. Sonuç model generation için kullanılabilir. Client progress state güncelleyebilir. Error sonucu ayrı status taşımalıdır.

citation

citation kullanılan kaynağı belirtir. Document ID veya URL metadata içerebilir. Client kaynak kartı gösterebilir. Citation event text token’dan ayrı tutulmalıdır. Kullanıcı yetkisi source link üzerinde de korunmalıdır.

usage

usage token ve maliyet bilgisini taşıyabilir. Genellikle stream sonunda gönderilir. Client analytics veya quota gösterebilir. Provider raw billing verisi normalize edilebilir. Hassas internal pricing kullanıcıya açılmayabilir.

error

error event stream başladıktan sonra oluşan hatayı bildirir. HTTP status artık değiştirilemeyebilir. Machine-readable code eklenmelidir. User-safe message ayrı alan olabilir. Retryable bilgisi client davranışını yönlendirebilir.

done

done stream’in başarıyla tamamlandığını belirtir. Final usage veya finish reason taşınabilir. Client loading state’i kapatır. Eksik done event bağlantı kesintisi olarak yorumlanabilir. Idempotency state server tarafında tamamlandı olarak işaretlenebilir.

Event Schema Versioning

Protocol version response header veya event içinde bulunabilir. Yeni field eklemek genellikle backward compatible’dir. Field kaldırmak dikkat gerektirir. Client eski version’u belirli süre destekleyebilir. Contract testleri CI pipeline’a eklenmelidir.

Backward Compatibility

Mobile client hemen güncellenmeyebilir. Server birden fazla event schema version destekleyebilir. Unknown event type client’ı crash ettirmemelidir. Mandatory field değişiklikleri version bump gerektirir. Deprecation süresi açıkça yönetilmelidir.

Event ID

Event ID her event’i benzersiz tanımlar. Reconnect ve duplicate detection için kullanılabilir. Global UUID veya stream-local ID olabilir. Durable storage gereksinimi ürün tasarımına bağlıdır. Log correlation için de faydalıdır.

Sequence Number

Sequence number stream içindeki sıralamayı gösterir. Client missing event tespit edebilir. Reconnection sırasında cursor görevi görebilir. Parallel event üretiminde sıralama açıkça tanımlanmalıdır. Duplicate event aynı sequence ile fark edilebilir.

Tool Calling Streaming Nasıl Yönetilir?

Tool calling streaming sırasında model yalnızca metin üretmez, araç çağrısı için parçalı argument da gönderebilir. Client bu argument parçalarını kullanıcı mesajı gibi render etmemelidir. Backend tool çağrısı tamamlandığında schema validation ve authorization yapmalıdır. Tool sonucu model context’ine eklenir ve generation devam eder. Tool failure client’a typed error veya status event olarak iletilebilir.

Text ve Tool Event'lerini Ayırmak

Text token ile tool argument aynı stream içinde olabilir. Typed event ayrımı zorunludur. UI tool progress’i farklı render edebilir. Backend tool event’i kendi state machine’inde işler. Model çıktısına doğrudan execute yetkisi verilmez.

Partial Tool Arguments

Model JSON argument’ı parça parça üretebilir. İlk chunk geçerli JSON olmayabilir. Buffer tamamlanana kadar parse bekletilebilir. Incremental parser kullanılabilir. Final schema validation zorunludur.

Tool Execution State

Tool pending, running, completed veya failed olabilir. State event client’a gönderilebilir. Aynı tool duplicate çalıştırılmamalıdır. Idempotency key kullanılabilir. Long-running tool asenkron job’a dönüşebilir.

Tool Result

Tool sonucu modelin devam eden context’ine eklenir. Sonuç büyükse gereksiz tamamı gönderilmemelidir. Hassas field’lar filtrelenmelidir. Model ve client için farklı view oluşturulabilir. Trace tool latency bilgisini saklamalıdır.

Model Generation'ın Devam Etmesi

Tool sonucu geldikten sonra model yeni inference çağrısı yapabilir. Kullanıcı stream aynı connection üzerinde devam edebilir. Event sequence korunmalıdır. Model değiştiyse metadata güncellenebilir. Tool sonrası TTFT ayrı ölçülebilir.

Tool Hatalarının Client'a İletilmesi

Tool failure tüm request’i sonlandırmak zorunda değildir. Model alternatif cevap üretebilir. Client progress alanında hata gösterebilir. Retry otomatik yapılacaksa idempotency kontrol edilmelidir. High-risk action için otomatik retry yapılmamalıdır.

Structured Output Streaming

Structured output stream etmek düz metne göre daha zordur çünkü JSON ancak tamamlandığında geçerli olabilir. Client yarım JSON parçalarını normal parse etmeye çalışırsa hata alır. Incremental parser veya typed field event yaklaşımı kullanılabilir. Final response tamamlandığında tam schema validation yapılmalıdır. Geçersiz yapı downstream otomasyona aktarılmamalıdır.

Partial JSON Problemi

İlk chunk yalnızca açılan süslü parantez içerebilir. Standart JSON parser bunu geçersiz sayar. Her chunk bağımsız belge değildir. Client buffer biriktirmelidir. UI raw JSON yerine field progress gösterebilir.

Incremental JSON Parsing

Incremental parser tamamlanan token yapısını takip edebilir. Büyük object’lerde erken field erişimi sağlar. Parser güvenli ve sınırlandırılmış olmalıdır. Derin nesting resource problemi yaratabilir. Final parse yine zorunludur.

Schema Validation

Final output beklenen schema ile doğrulanmalıdır. Required field ve type kontrol edilir. Enum değerleri sınırlandırılır. Tool execution bu validasyondan sonra yapılmalıdır. Hatalı output için controlled retry uygulanabilir.

UI'nın Eksik JSON ile Çalışması

UI partial object’i final veri gibi kullanmamalıdır. Field tamamlanma state’i gösterilebilir. Eksik value placeholder olarak tutulabilir. Render logic parse error nedeniyle crash etmemelidir. Final event geldiğinde state doğrulanır.

Final Validation

Stream bitince tüm object yeniden parse edilir. Schema validation çalıştırılır. İş kuralı kontrolü ayrıca yapılır. Başarı sonrası downstream işlem tetiklenir. Invalid result log ve eval sistemine gönderilebilir.

Geçersiz Structured Output Yönetimi

Geçersiz output kullanıcıya ham hata olarak gösterilmemelidir. Modelden düzeltme istenebilir. Retry sayısı sınırlandırılmalıdır. Aynı invalid pattern evaluation dataset’e eklenebilir. Kritik otomasyonda insan onayı gerekebilir.

Backpressure Nedir?

Backpressure producer’ın consumer’dan daha hızlı veri üretmesi durumunda akışın kontrollü yavaşlatılmasıdır. LLM provider backend’in işleyebileceğinden hızlı token gönderebilir. Backend de mobil istemcinin okuyabileceğinden hızlı veri iletebilir. Buffer sınırsız büyürse memory problemi oluşur. Flow control ve buffer limitleri production streaming sistemlerinin temel parçalarıdır.

Producer ve Consumer Hız Farkı

Producer veri üretir. Consumer bu veriyi işler. Hızlar farklı olduğunda queue oluşur. Sınırsız queue memory kullanır. Backpressure üretimi veya okumayı geçici yavaşlatır.

LLM Provider → Backend Backpressure

Backend provider stream’ini hızlı okuyabilir. Ancak downstream client yavaş olabilir. Provider data buffer’da birikmemelidir. Streaming API flow control destekliyorsa kullanılmalıdır. Gerektiğinde request iptal edilebilir.

Backend → Client Backpressure

Server socket write buffer dolabilir. Slow client data’yı tüketmiyordur. Server write işlemi beklemelidir. Bu connection başına memory kullanımını artırabilir. Maximum buffer policy gerekir.

Yavaş Mobil İstemciler

Mobil ağ throughput dalgalanabilir. Client kısa süre internet kaybedebilir. Buffer hızla büyüyebilir. Connection drop tespit edilmelidir. Resume veya retry UX’i sağlanmalıdır.

Memory Buffer Büyümesi

Her açık stream ayrı buffer kullanabilir. Binlerce connection küçük bufferlarla bile büyük memory tüketebilir. Limit aşılırsa connection kapatılabilir. Metrics buffer kullanımını izleyebilir. Load test slow client senaryosu içermelidir.

Flow Control

Flow control üretim ile tüketim hızını dengeler. HTTP/2 ve TCP seviyesinde mekanizmalar vardır. Uygulama buffering’i yine ayrıca yönetmelidir. Queue uzunluğu feedback sinyali olabilir. Çok agresif flow control throughput düşürebilir.

Buffer Limitleri

Her connection için maksimum buffer belirlenmelidir. Aşım durumunda policy uygulanır. Client çok yavaşsa stream sonlandırılabilir. Partial response kullanıcıya gösterilebilir. Limit kapasite testlerinden çıkarılmalıdır.

Token Buffering Nasıl Yapılmalı?

Her tokenı ayrı network write ile göndermek teorik olarak en hızlı görünse de pratikte overhead oluşturabilir. Birkaç token veya birkaç milisaniyelik pencere içinde chunk toplamak daha verimli olabilir. Buffer çok büyürse TTFT sonrası akış kesikli görünür. Frontend de her chunk için pahalı markdown render işlemi yapmamalıdır. UX ve network maliyeti birlikte ölçülerek flush politikası belirlenmelidir.

Her Token'ı Ayrı Göndermek

Her token anında client’a iletilebilir. Latency düşük görünür. Ancak sistem call ve packet overhead artar. UI render sayısı yükselir. Yüksek concurrency’de verimsiz olabilir.

Chunk Bazlı Gönderim

Birkaç token tek event içinde gruplanır. Network overhead azalır. Client daha az render yapar. Çok büyük chunk akıcılığı azaltabilir. Optimal boyut benchmark ile seçilmelidir.

Zaman Bazlı Flush

Buffer belirli milisaniye aralığında gönderilir. Token sayısı değişken olabilir. Kullanıcı akışı düzenli görür. Çok kısa interval overhead yaratır. Çok uzun interval gecikme hissi verir.

Boyut Bazlı Flush

Buffer belirli byte veya karakter boyutuna ulaşınca gönderilir. Network paketleri daha verimli kullanılabilir. Düşük token hızında uzun bekleme oluşabilir. Zaman limitiyle birlikte kullanılabilir. UTF-8 karakter sınırları doğru yönetilmelidir.

UX ve Network Overhead Dengesi

Kullanıcı çok küçük farkları algılamayabilir. On milisaniyelik batching büyük verim sağlayabilir. Gerçek değer cihaz ve ağ koşullarında test edilmelidir. TTFT ilk chunk için ayrı optimize edilmelidir. Sonraki chunk interval daha büyük olabilir.

Frontend Rendering Performansı

Her chunk’ta tüm markdown yeniden parse edilmemelidir. Incremental render veya debounce kullanılabilir. Code block syntax highlight tamamlandığında çalıştırılabilir. Mobile CPU performansı dikkate alınmalıdır. Rendering latency observability ile ölçülebilir.

Client Disconnect Nasıl Yönetilir?

Kullanıcı sekmeyi kapattığında veya mobil bağlantısı koptuğunda backend’in bunu fark etmesi gerekir. Aksi halde LLM provider token üretmeye devam eder. Bu durum gereksiz GPU veya API maliyeti oluşturur. Disconnect signal upstream cancellation’a kadar propagate edilmelidir. LLM uygulamalarında streaming yanıt timeout güvenlik ve bağlantı yönetimi açısından bu davranış production kalitesini doğrudan etkiler.

Kullanıcının Sekmeyi Kapatması

Browser connection kapanır. Server socket disconnect sinyali alabilir. Request context cancelled olarak işaretlenir. Upstream provider isteği iptal edilir. Partial response state gerektiğinde saklanır.

Mobil İnternetin Kopması

Network disconnect her zaman anında tespit edilmeyebilir. TCP timeout devreye girer. Heartbeat daha hızlı tespit sağlayabilir. Client reconnect yapabilir. Duplicate generation engellenmelidir.

AbortController

Browser fetch request AbortController ile iptal edilebilir. Stop button bu mekanizmayı kullanabilir. Client local stream reader kapanır. Server bağlantı kapanmasını görmelidir. Ayrı cancellation endpoint gerekiyorsa request ID kullanılabilir.

Server-Side Disconnect Detection

Framework client disconnect event sağlayabilir. Handler inference task’ını cancel eder. Background task request context’ten kopuk çalışmamalıdır. Connection kapanması loglanabilir. Cancellation rate ürün davranışı hakkında bilgi verir.

Upstream LLM Request'i İptal Etmek

HTTP client request context cancellation desteklemelidir. Provider connection kapatılır. Self-hosted model server cancellation event alabilir. Her provider gerçek compute’ı anında durdurmayabilir. Yine de mümkün olan en erken noktada iptal gönderilmelidir.

Gereksiz Token Maliyetini Önlemek

Kullanıcının görmediği token için ödeme yapmak istenmez. Disconnect cancellation maliyeti azaltır. Usage kaydı gerçek tüketimi göstermelidir. Provider billed token ile client received token farklı olabilir. Bu fark dashboard’da izlenebilir.

Kullanıcı "Durdur" Butonuna Bastığında Ne Olur?

Stop butonu yalnızca frontend animasyonunu durdurmamalıdır. Client aktif stream’i cancel etmelidir. Backend bu iptali upstream model çağrısına iletmelidir. Conversation state partial response için doğru biçimde güncellenmelidir. Usage ve billing bilgisi generation tamamlanmamış olsa bile kaydedilmelidir.

Client Cancellation

Client AbortController tetikler. Stream reader kapanır. UI loading state’i değişir. Kullanıcı partial cevabı görmeye devam edebilir. Aynı message ID ile yeni generation başlatılmamalıdır.

Backend Cancellation

Backend request context’in iptal edildiğini görür. Background model task durdurulur. Tool execution varsa güvenli biçimde sonlandırılır. Database transaction gerekli noktada tamamlanır. Cancellation event trace’e eklenir.

Provider Cancellation

Backend upstream HTTP request’i kapatır. Provider streaming sonlanır. Provider support ediyorsa explicit cancel API kullanılabilir. Bazı provider’lar generation’ı hemen durdurmayabilir. Kullanım metriği buna göre hesaplanmalıdır.

Veritabanı State Güncellemesi

Message status cancelled olarak kaydedilebilir. Partial text tutulabilir. Final completion flag false olur. Retry yeni message veya generation ID oluşturabilir. Audit için cancellation timestamp saklanabilir.

Partial Response'un Saklanması

Kullanıcı yarım yanıtı görmek isteyebilir. Product policy partial metni saklayabilir. Tool result sonrası incomplete state ayrıca işaretlenmelidir. Hassas veri retention politikasına tabi olmalıdır. Resume için partial text tek başına yeterli olmayabilir.

Billing ve Usage Kaydı

Completion tamamlanmasa bile token kullanılmıştır. Provider usage değeri mevcutsa saklanmalıdır. Client’a gösterilen token sayısı ayrıca tutulabilir. Chargeback policy cancelled request’i nasıl ele alacağını tanımlamalıdır. Duplicate billing idempotency ile azaltılmalıdır.

Streaming Ortasında Hata Oluşursa Ne Yapılmalı?

Streaming başladıktan sonra klasik HTTP hata yönetimi değişir çünkü response header çoktan gönderilmiş olabilir. Bu durumda HTTP status kodunu 500’e çevirmek mümkün değildir. Hata stream içinde typed error event olarak iletilebilir. Client partial response’u koruyup retry seçeneği sunabilir. Provider timeout, 429 veya tool failure gibi hatalar farklı retry politikasına sahip olmalıdır.

Headers Gönderildikten Sonra HTTP Status Problemi

HTTP status stream başlamadan gönderilir. İlk token sonrası status değiştirilemez. Sonraki hata body içinde bildirilmelidir. Typed error event bu nedenle önemlidir. Client done event gelmemesini de failure olarak algılayabilir.

In-Band Error Event

Error event stream içinde normal event gibi taşınır. Error code machine-readable olmalıdır. Message kullanıcıya güvenli ifade sunmalıdır. Retryable flag eklenebilir. Client stream’i sonlandırır ve uygun UI gösterir.

Provider Timeout

Provider belirlenen süre içinde token üretmeyebilir. Backend upstream request’i iptal eder. Eğer stream başlamadıysa 504 benzeri status döndürülebilir. Başladıysa in-band error gerekir. Retry request’in idempotency durumuna göre yapılmalıdır.

429 Rate Limit

Provider rate limit uygulayabilir. Retry-After bilgisi dikkate alınmalıdır. Aynı anda otomatik çok sayıda retry yapılmamalıdır. Fallback provider kullanılabilir. Kullanıcıya geçici yoğunluk mesajı gösterilebilir.

Network Disconnect

Backend ile provider arasındaki connection kopabilir. Partial tokenlar client’a ulaşmış olabilir. Otomatik yeniden generation duplicate text üretebilir. Resume desteği yoksa kontrollü retry daha güvenlidir. UI partial response’u işaretlemelidir.

Content Filter

Provider generation’ı content policy nedeniyle durdurabilir. Finish reason client’a typed event olarak iletilebilir. Kullanıcıya uygun açıklama gösterilmelidir. Internal policy ile provider policy farklı olabilir. Bu olay error metric’inden ayrı sınıflandırılabilir.

Tool Failure

Tool endpoint timeout olabilir. Model alternatif cevap verebilir. Retry edilecekse action idempotency kontrol edilmelidir. Write tool otomatik retry risklidir. Client tool failure state’i görebilir.

Partial Response

Partial text kullanıcı için yine değerli olabilir. UI bunu tamamlanmamış olarak işaretlemelidir. Conversation history’ye nasıl ekleneceği ürün kararıdır. Retry sırasında aynı partial text iki kez görünmemelidir. Server message status incomplete tutabilir.

Kullanıcıya Retry Seçeneği Sunmak

Retry yeni request başlatabilir. Önceki request ID referans olarak gönderilebilir. Aynı billing işlemi yanlışlıkla tekrar yapılmamalıdır. Model context partial response’u içerip içermeyeceği belirlenmelidir. Kullanıcı retry sonucunun yeni generation olduğunu anlayabilmelidir.

Timeout Yönetimi

AI uygulamalarında tek bir timeout değeri yoktur. Connection, request, read, idle, stream ve gateway timeout’ları farklı amaçlara hizmet eder. Katmanlardan biri diğerlerinden çok kısa timeout kullanırsa kullanıcı beklenmedik kesinti görür. Çok uzun timeout ise resource exhaustion riskini artırır. Tüm timeout zinciri birlikte tasarlanmalı ve production network koşullarında test edilmelidir.

Connection Timeout

Connection timeout upstream’e bağlantı kurmak için izin verilen süredir. DNS ve TCP sorunlarında devreye girer. Inference süresinden daha kısa tutulabilir. Çok uzun değer thread veya connection slot tüketebilir. Provider bazında ayarlanabilir.

Request Timeout

Request timeout işlemin toplam üst sınırıdır. Uzun generation için yeterli olmalıdır. Asenkron job’larda farklı model uygulanır. Kullanıcı stop verdiğinde bu süre beklenmez. Timeout sonrası upstream cancellation yapılmalıdır.

Read Timeout

Read timeout socket’ten veri gelmeden ne kadar bekleneceğini belirler. Streaming’de tokenlar arası uzun sessizlik olabilir. Çok kısa değer normal generation’ı kesebilir. Çok uzun değer ölü bağlantıyı geç fark eder. Heartbeat ile birlikte değerlendirilebilir.

Idle Timeout

Idle timeout hiçbir trafik olmayan bağlantıyı kapatır. Load balancer ve proxy katmanlarında bulunur. SSE keep-alive bu süreyi aşmayı önleyebilir. WebSocket heartbeat benzer amaç taşır. Tüm katmanların değerleri uyumlu olmalıdır.

Stream Timeout

Stream için maksimum açık kalma süresi tanımlanabilir. Sonsuz generation engellenir. Long-running agent işlerinde daha yüksek değer gerekebilir. Süre dolunca error event gönderilebilir. Client retry veya job mode’a yönlendirilebilir.

Gateway Timeout

API Gateway upstream response için limit uygulayabilir. Varsayılan değer LLM için kısa olabilir. Streaming support ve idle timeout ayrı kontrol edilmelidir. Gateway configuration staging’de test edilmelidir. 504 metric’i izlenmelidir.

CDN Timeout

CDN origin connection sürelerini sınırlayabilir. Streaming response özel davranış gösterebilir. Buffering veya idle timeout problemi olabilir. Provider değil CDN request’i kesiyor olabilir. Production troubleshooting’de bu katman unutulmamalıdır.

Provider Timeout

Backend provider’a ayrı timeout tanımlar. Bir provider daha uzun inference süresi gerektirebilir. Fallback öncesi bekleme süresi kullanıcı SLO’suyla uyumlu olmalıdır. Provider timeout metric’i ayrı tutulmalıdır. Retries latency budget’ı aşmamalıdır.

Timeout Değerlerinin Katmanlar Arasında Uyumlandırılması

Client timeout gateway’den biraz daha uzun olabilir. Gateway backend timeout’tan önce bağlantıyı kesmemelidir. Backend provider timeout’unu kendi toplam budget’ı içinde tutmalıdır. Idle timeout heartbeat interval’dan uzun olmalıdır. Bu değerler architecture runbook içinde belgelenmelidir.

Retry Stratejileri

Retry geçici network hatalarını azaltabilir ancak yanlış tasarlanırsa aynı pahalı AI isteğini defalarca çalıştırabilir. Hangi hata kodlarının retry edileceği açık biçimde belirlenmelidir. Exponential backoff ve jitter aynı anda binlerce istemcinin yeniden bağlanmasını engeller. Streaming başladıktan sonra retry daha zordur çünkü kullanıcı partial response görmüştür. Retry budget toplam request süresini kontrol altında tutmalıdır.

Hangi Hatalar Retry Edilmeli?

Geçici 502 veya 503 hataları retry adayı olabilir. Connection reset tekrar denenebilir. 429 Retry-After ile yeniden denenebilir. DNS transient failure kısa retry alabilir. Write tool işlemleri ayrı idempotency kontrolü gerektirir.

Hangi Hatalar Retry Edilmemeli?

Authentication 401 genellikle otomatik retry edilmemelidir. Invalid request 400 aynı payload ile düzelmez. Policy rejection tekrar denenmemelidir. Non-idempotent tool action risklidir. Retry öncesi hata sınıfı belirlenmelidir.

Exponential Backoff

Her retry arasındaki süre kademeli artar. Provider’a ani yük bindirilmez. İlk retry kısa olabilir. Maksimum bekleme sınırı tanımlanmalıdır. User latency budget aşılmamalıdır.

Jitter

Jitter bekleme süresine rastgelelik ekler. Binlerce client aynı anda retry yapmaz. Thundering herd riski azalır. Backoff ile birlikte kullanılır. Maximum delay korunmalıdır.

Retry-After

Provider 429 veya 503 response içinde Retry-After döndürebilir. Client veya backend bu değeri dikkate almalıdır. Kullanıcı request’inde çok uzun değer kabul edilmeyebilir. Asenkron job daha sonra devam edebilir. Fallback provider alternatif olabilir.

Retry Budget

Toplam retry sayısı ve süresi sınırlanmalıdır. Bir request sonsuz döngüye girmemelidir. Budget latency SLO’ya bağlanabilir. Her retry cost metriğine eklenmelidir. Retry oranı yüksekse kök neden araştırılmalıdır.

Streaming Başladıktan Sonra Retry Problemi

Client zaten partial text almıştır. Yeni request baştan üretim yapabilir. Aynı text tekrar görülebilir. Resume destekleniyorsa stream cursor kullanılabilir. Aksi halde kullanıcıya açık retry seçeneği sunmak daha güvenlidir.

Idempotency ve Duplicate AI İstekleri

Network retry veya kullanıcı çift tıklaması aynı generation’ın birden fazla kez başlamasına neden olabilir. Bu durum gereksiz maliyet ve karışık conversation state üretir. Idempotency key aynı logical request’in tekrarlarını tanımayı sağlar. Server mevcut generation sonucunu veya state’ini döndürebilir. Billing sistemi de aynı idempotency key üzerinden duplicate charge oluşmasını engelleyebilir.

Idempotency Nedir?

Idempotency aynı logical işlemin tekrar gönderildiğinde tek kez etkili olmasıdır. GET işlemleri doğal olarak idempotent olabilir. LLM generation ise yeni maliyet üretebilir. Application-level idempotency key gerekir. State belirli retention süresi boyunca saklanır.

Network Retry Sonrası Aynı Generation'ın İki Kez Başlaması

Client timeout alabilir ama server işlemeye devam ediyor olabilir. Retry yeni generation başlatabilir. Kullanıcı iki response görür. Provider iki kez ücretlendirebilir. Idempotency bu riski azaltır.

Request ID

Request ID her fiziksel HTTP çağrısını tanımlar. Trace correlation için kullanılır. Retry’de yeni request ID üretilebilir. Logical operation için ayrı idempotency key daha uygundur. Loglarda iki değer birlikte saklanabilir.

Idempotency Key

Client veya backend UUID üretir. Aynı logical request retry edildiğinde key değişmez. Server state store üzerinden mevcut işlemi bulur. Completed result yeniden döndürülebilir. In-progress stream için resume veya conflict davranışı tanımlanmalıdır.

Duplicate Stream Detection

Aynı idempotency key ile ikinci stream açılırsa server bunu fark eder. Mevcut stream’e attach etmek mümkün olabilir. Alternatif olarak 409 benzeri yanıt döndürülebilir. Duplicate request loglanır. Client bug veya network retry pattern’i analiz edilebilir.

Duplicate Billing Riski

İki generation iki ayrı token maliyeti oluşturur. Usage sistemi logical request ile provider request’leri eşleştirmelidir. Fallback çağrıları da ayrı maliyet olarak kaydedilir. Billing duplicate kontrolü bağımsız uygulanmalıdır. Cost anomaly monitoring faydalıdır.

SSE Reconnect Sonrası Duplicate Generation Nasıl Önlenir?

SSE bağlantısı koptuğunda client’ın yeniden bağlanması generation’ın baştan başlamasına neden olmamalıdır. Bunun için request state ve event cursor bilgisi server tarafında yönetilebilir. Event ID son görülen parçayı gösterir. Resume desteği olmayan sistemlerde eski generation iptal edilip kullanıcıya açık restart seçeneği sunulabilir. Tasarım baştan belirlenmezse mobil kullanıcılar duplicate token ve maliyet sorunuyla karşılaşabilir.

Event ID

Her SSE event benzersiz veya sıralı ID taşıyabilir. Client son ID’yi saklar. Reconnect request’inde bu değer gönderilebilir. Server sonraki event’i bulabilir. Event history retention gerekir.

Resume Token

Resume token stream state’ine referans verir. İmzalı veya opaque değer olabilir. Client server state detaylarını bilmez. Token expiration tanımlanmalıdır. Security açısından başka kullanıcının stream’ine erişim sağlamamalıdır.

Request State

Server generation state’ini active, completed veya failed olarak tutabilir. Reconnect bu kaydı sorgular. Active stream buffer’dan devam edilebilir. Completed result yeniden aktarılabilir. State store kapasitesi planlanmalıdır.

Stream Cursor

Cursor client’ın hangi event’e kadar aldığını gösterir. Sequence number kullanılabilir. Server missing event’leri yeniden gönderir. Çok büyük buffer gereksinimi oluşabilir. Product ihtiyaçlarına göre kısa retention yeterli olabilir.

Önceki Generation'ı İptal Etmek

Resume desteklenmiyorsa eski generation iptal edilebilir. Yeni request açık kullanıcı aksiyonuyla başlatılır. Duplicate cost azalır. Partial text kullanıcıya korunabilir. Conversation state yeni generation için doğru hazırlanmalıdır.

Resume vs Restart Kararı

Kısa network kopmalarında resume iyi UX sağlar. Çok uzun kopmada state saklamak pahalı olabilir. Deterministic tool workflow restart için riskli olabilir. Server policy süre ve görev tipine göre karar verebilir. Kullanıcıya durum açıkça gösterilmelidir.

Mobil Ağlarda AI İletişimi

Mobil istemciler masaüstü kablolu ağlara göre daha değişken network koşullarında çalışır. Latency artabilir, paket kaybı oluşabilir ve cihaz Wi-Fi ile 5G arasında geçiş yapabilir. Uzun AI stream’leri bu değişimlerden etkilenir. Reconnection ve partial response recovery mobile-first düşünülmelidir. Offline state ve request queue kullanıcı deneyimini iyileştirebilir.

Yüksek Latency

Mobil round-trip süresi yüksek olabilir. TTFT desktop’a göre artar. Connection reuse daha önemli hale gelir. UI streaming sayesinde bekleme hissini azaltabilir. Region seçimi coğrafi latency’yi etkiler.

Paket Kaybı

Paket kaybı TCP throughput’u düşürebilir. Stream takılarak ilerleyebilir. HTTP/3 bazı durumlarda avantaj sağlar. Client timeout aşırı agresif olmamalıdır. Network quality metric product analytics’e eklenebilir.

4G/5G ve Wi-Fi Geçişleri

Cihaz network interface değiştirebilir. TCP connection kopabilir. QUIC migration bazı durumlarda bağlantıyı koruyabilir. Uygulama yine reconnect state hazırlamalıdır. Generation duplicate olmamalıdır.

Connection Drop

Uzun stream sırasında bağlantı tamamen kesilebilir. Client incomplete state gösterir. Reconnect otomatik veya kullanıcı kontrollü olabilir. Server old stream’i cleanup etmelidir. Upstream cancellation maliyeti azaltır.

Reconnection

Exponential backoff kullanılabilir. Network online event takip edilebilir. Session ve request ID yeniden gönderilir. Resume destekleniyorsa cursor kullanılır. Kullanıcıya yeniden bağlanılıyor mesajı gösterilebilir.

Offline State

Cihaz internet olmadığını tespit edebilir. Yeni generation hemen gönderilmemelidir. Kullanıcı mesajı local queue’da saklanabilir. Hassas veri local storage policy’ye tabi olmalıdır. Online olduğunda kullanıcı onayıyla gönderilebilir.

Request Queue

Offline mesajlar sıraya alınabilir. Her mesaj idempotency key taşır. Network geri gelince kontrollü gönderilir. Çok eski request context’i geçersiz olabilir. Conversation state reconciliation yapılmalıdır.

Partial Response Recovery

Kullanıcı aldığı partial text’i kaybetmemelidir. Reconnect sonrası devam veya retry seçeneği sunulabilir. Server completed response varsa geri dönebilir. UI duplicate text birleştirmemelidir. Message status açık biçimde gösterilmelidir.

Proxy ve Reverse Proxy Streaming'i Nasıl Etkiler?

Streaming localhost ortamında çalışıp production’da gecikiyorsa ilk kontrol edilmesi gereken katmanlardan biri reverse proxy’dir. Proxy response’u buffer ederek tokenları tek seferde client’a gönderebilir. Read timeout uzun LLM istekleri için yetersiz olabilir. Compression küçük streaming chunk’larında beklenmeyen buffering oluşturabilir. Nginx ve benzeri proxy ayarları gerçek streaming yüküyle test edilmelidir.

Nginx

Nginx AI backend önünde reverse proxy olarak kullanılabilir. Streaming endpoint için özel ayar gerekebilir. Timeout değerleri uzun response’a uygun olmalıdır. Buffering kapatılabilir. WebSocket kullanılıyorsa upgrade header geçirilmelidir.

Proxy Buffering

Proxy backend response parçalarını memory veya disk üzerinde biriktirebilir. Client tokenları geç görür. SSE endpoint’te buffering genellikle istenmez. Route bazında kapatılmalıdır. Değişiklik sonrası TTFT test edilmelidir.

Response Buffering

Application server veya framework de buffering yapabilir. Proxy ayarı tek başına yeterli olmayabilir. Flush davranışı kontrol edilmelidir. Middleware response’u sıkıştırıp biriktirebilir. Tüm zincir uçtan uca test edilmelidir.

Read Timeout

Proxy backend’den belirli süre veri gelmezse bağlantıyı kapatabilir. Model ilk tokenı geç üretiyorsa sorun oluşur. Keep-alive event yardımcı olabilir. Timeout sonsuz yapılmamalıdır. SLO ve maximum generation süresine göre ayarlanmalıdır.

Keep-Alive

Client-proxy ve proxy-backend connection reuse farklı ayarlara sahiptir. Long stream tek connection’ı uzun süre kullanır. Idle keep-alive yeni request reuse için önemlidir. Backend pool limitleri takip edilmelidir. Connection header yanlış yönetilmemelidir.

Compression

Compression metin response boyutunu azaltabilir. Ancak küçük chunk’lar compressor buffer’da bekleyebilir. Streaming latency artabilir. SSE endpoint’te compression test edilmelidir. Network tasarrufu ile TTFT sonrası akış dengelenmelidir.

X-Accel-Buffering

Nginx belirli header üzerinden buffering davranışını kontrol edebilir. X-Accel-Buffering no streaming endpoint’lerde kullanılabilir. Global ayar yerine route bazlı yaklaşım daha güvenlidir. CDN veya başka proxy yine buffer edebilir. Header production trace ile doğrulanmalıdır.

CDN ve Edge Katmanı

CDN ve edge katmanı authentication, WAF ve geo routing gibi görevlerle AI uygulamasına değer sağlayabilir. Ancak dynamic streaming response klasik static cache davranışından farklıdır. Edge runtime execution limitleri uzun LLM bağlantılarını etkileyebilir. Origin timeout doğru ayarlanmalıdır. Streaming destek ve buffering davranışı kullanılan platformda açıkça test edilmelidir.

Edge'in AI Mimarisindeki Rolü

Edge kullanıcıya yakın ilk giriş noktası olabilir. TLS termination ve WAF burada çalışabilir. Basit authentication check yapılabilir. Ağ latency’si azalabilir. LLM orchestration’ın tamamını edge’e taşımak her zaman gerekli değildir.

Authentication'ı Edge'de Yapmak

JWT signature edge’de doğrulanabilir. Geçersiz request origin’e ulaşmaz. Authorization’ın tümü burada tutulmak zorunda değildir. User context güvenli header ile backend’e aktarılabilir. Spoofed internal header temizlenmelidir.

Rate Limiting

Edge bot ve abuse request’lerini erken kesebilir. IP ve token bazlı limit uygulanabilir. AI-specific token budget backend’de devam edebilir. Global distributed rate limit daha zordur. False positive kullanıcıyı gereksiz engellememelidir.

Geo Routing

Kullanıcı en yakın backend region’a yönlendirilebilir. TTFT ağ kısmı azalabilir. Model kapasitesi region’lar arasında farklı olabilir. Data residency routing kararını sınırlandırabilir. Health durumuna göre failover yapılabilir.

Streaming ve CDN Cache

Dynamic LLM stream çoğu zaman cache edilmez. CDN response’u pass-through ile iletir. Semantic cache backend veya edge application katmanında uygulanabilir. Kullanıcıya özel response paylaşılmamalıdır. Cache-Control header doğru ayarlanmalıdır.

Edge Runtime Limitleri

Edge function maksimum çalışma süresine sahip olabilir. Long stream bu sınırı aşabilir. Memory ve connection limitleri incelenmelidir. Provider socket desteği farklı olabilir. Production architecture platform limitleriyle uyumlu olmalıdır.

Origin Timeout

CDN origin’den ilk veya sonraki byte’ı bekler. Model TTFT bu süreyi aşarsa bağlantı kesilebilir. Keep-alive event çözüm olabilir. Timeout artırmak tek başına capacity sorununu çözmez. Provider queue metric de izlenmelidir.

API Gateway'in AI Uygulamalarındaki Rolü

API Gateway AI uygulamalarında yalnızca route yönlendiren bir proxy değildir. Kullanıcı kimliği, rate limit, provider routing, logging ve cost metering aynı noktada uygulanabilir. Multi-provider mimaride provider health durumuna göre trafik dağıtılabilir. Circuit breaker sorunlu servise gereksiz request gönderilmesini engeller. Gateway doğru tasarlandığında istemciler model veya provider detaylarından bağımsız kalır.

Authentication

Gateway access token doğrulayabilir. Invalid request backend’e ulaşmaz. Service-to-service credential ayrıca kontrol edilir. Identity bilgisi downstream’e güvenli şekilde aktarılır. Token payload loglara yazılmamalıdır.

Authorization

Kullanıcının belirli model veya feature erişimi kontrol edilebilir. Tenant planı farklı limitlere sahip olabilir. High-cost model yalnızca yetkili role açılabilir. Fine-grained data authorization yine backend’de yapılabilir. Gateway policy merkezi yönetim sağlar.

Rate Limiting

Gateway request ve connection limit uygular. Concurrent SSE stream sayısı takip edilebilir. Tenant bazlı quota desteklenebilir. Burst ve sustained rate ayrı olabilir. 429 response standardize edilir.

Request Routing

Path veya model parametresine göre backend seçilebilir. Chat ve embedding farklı service’e gider. Canary deployment belirli trafik yüzdesini yeni backend’e yönlendirir. Geo routing eklenebilir. Route değişimi client’tan gizlenir.

Provider Routing

Gateway veya provider gateway istekleri farklı LLM servislerine yönlendirebilir. Cost veya latency kriteri kullanılabilir. Hassas data yalnızca kurum içi modele gidebilir. Provider outage fallback tetikleyebilir. Routing kararı trace metadata’ya eklenmelidir.

Logging

Gateway request metadata kaydeder. Prompt body default olarak loglanmamalıdır. Status ve duration yeterli olabilir. Correlation ID backend’e aktarılır. Hassas header’lar maskelenmelidir.

Cost Metering

Model ve provider usage bilgisi merkezi toplanabilir. Token sayısı tenant’a atanır. Budget threshold alarm üretir. Cache hit request maliyeti ayrı hesaplanabilir. Showback ürün ekiplerinin farkındalığını artırır.

Request Transformation

Client ortak contract kullanabilir. Gateway provider-specific payload’a dönüştürür. Response event formatı normalize edilir. Tool schema farklılıkları adapter ile yönetilir. Aşırı transformation debugging’i zorlaştırmamalıdır.

Circuit Breaker

Provider sürekli hata veriyorsa circuit açılır. Yeni request’ler hızlıca fallback’e yönlendirilir. Belirli süre sonra half-open test yapılır. Recovery doğrulanırsa trafik geri verilir. Error threshold gerçek trafik hacmine göre belirlenmelidir.

Load Balancing ve AI Backend Ölçeklendirme

AI backend çoğu zaman modelin kendisinden bağımsız olarak yatay ölçeklenebilir. Stateless tasarım load balancer kullanımını kolaylaştırır. WebSocket gibi uzun bağlantılarda mevcut connection zaten belirli instance üzerinde kalır. SSE genellikle standart HTTP load balancing ile iyi çalışır. Health check yalnızca portun açık olup olmadığını değil servis bağımlılıklarının durumunu da değerlendirmelidir.

Stateless Backend

Request state shared database veya Redis üzerinde tutulur. Her instance aynı request’i işleyebilir. Horizontal scaling kolaylaşır. Deployment sırasında connection draining yapılabilir. Local memory yalnızca cache olarak kullanılmalıdır.

Stateful Backend

Conversation veya stream state instance memory’sinde tutulabilir. Sticky session gereksinimi doğar. Instance kaybı state kaybına neden olabilir. Scale-in daha zor hale gelir. Paylaşılan state mümkünse tercih edilmelidir.

Round Robin

Request’ler backend instance’larına sırayla dağıtılır. Kısa request’lerde basit ve etkilidir. Uzun stream süreleri dengesiz yük oluşturabilir. Instance connection sayıları farklılaşabilir. Least connections daha uygun olabilir.

Least Connections

Load balancer en az aktif bağlantısı olan backend’i seçer. Uzun SSE veya WebSocket için faydalıdır. Connection sayısı gerçek compute yükünü tam göstermeyebilir. Bazı stream’ler daha fazla kaynak tüketebilir. Yine de round robin’e göre dengeli sonuç verebilir.

Sticky Session

Client belirli backend’e yönlendirilir. Local state kullanılıyorsa gerekebilir. Instance failure reconnect problemi oluşturur. Load distribution kötüleşebilir. Stateless architecture’da mümkün olduğunca kaçınılmalıdır.

WebSocket Connection Affinity

WebSocket connection açıldıktan sonra aynı backend ile devam eder. Reconnect yeni instance’a gidebilir. Session state shared storage’dan yüklenmelidir. Load balancer upgrade desteği sunmalıdır. Graceful drain mevcut connection’ları korumalıdır.

SSE ve Load Balancer

SSE normal HTTP response olarak load balancer’dan geçer. Connection uzun süre açık kalır. Idle timeout doğru ayarlanmalıdır. Buffering yapılmamalıdır. Scale-in öncesi connection draining gerekir.

Health Check

Health endpoint process durumundan fazlasını gösterebilir. Upstream bağımlılığı tamamen down ise readiness false olabilir. Liveness ve readiness ayrılmalıdır. Ağır model call health check’te çalıştırılmamalıdır. Fakat kritik connection pool problemi görünür olmalıdır.

Uzun Süreli Bağlantılarda Capacity Planning

Streaming AI sistemlerinde yalnızca Requests Per Second metriği kapasiteyi açıklamaz. Bir request onlarca saniye açık kalabilir. Bu nedenle concurrent connection sayısı, connection başına memory ve file descriptor limiti hesaplanmalıdır. Network bandwidth sürekli token veya audio akışından etkilenir. Connection headroom peak trafik ve deployment sırasında kapasite kaybını karşılayacak şekilde bırakılmalıdır.

Requests Per Second Yerine Concurrent Connections

RPS düşük görünse bile stream süresi uzunsa binlerce connection açık olabilir. Little’s Law benzeri yaklaşımlar tahmin sağlar. Ortalama connection süresi ölçülmelidir. Peak concurrency ayrıca hesaplanmalıdır. Load test gerçek stream süresini kullanmalıdır.

Ortalama Stream Süresi

Chat response ortalama süresi capacity hesabını etkiler. Uzun document generation daha fazla connection tutar. P95 stream duration da önemlidir. Product max token limiti süreyi sınırlar. Çok uzun işler job modeline taşınabilir.

Maksimum Connection Sayısı

Backend instance socket sınırına sahiptir. Reverse proxy ve load balancer limitleri de vardır. Maximum connection testle doğrulanmalıdır. Limit aşılırsa admission control yapılabilir. Autoscaling connection metric kullanabilir.

File Descriptor Limitleri

Her socket file descriptor kullanır. İşletim sistemi varsayılan limiti düşük olabilir. Nginx ve application process ayrı limitlere sahiptir. Kör şekilde yükseltmek memory riskini çözmez. Monitoring descriptor kullanımını takip etmelidir.

Memory per Connection

Her stream buffer ve state tutar. Küçük miktarlar binlerce connection’da büyür. WebSocket state daha fazla olabilir. Slow client buffer kullanımı yükseltir. Load test memory trendini göstermelidir.

Network Bandwidth

Text streaming nispeten düşük bandwidth kullanır. Audio ve multimodal trafik daha ağırdır. Egress kapasitesi ölçülmelidir. Compression fayda ve latency açısından test edilmelidir. Regional deployment cross-region trafiğini azaltabilir.

Connection Headroom

Sistem yüzde yüz kapasitede çalışmamalıdır. Ani trafik veya node kaybı için pay bırakılmalıdır. Deployment sırasında bazı instance’lar drain olabilir. Headroom SLO’ya göre belirlenir. Autoscaling startup süresi de hesaba katılmalıdır.

Graceful Shutdown ve Connection Draining

Yeni sürüm deploy edilirken aktif AI stream’lerinin aniden kopması kötü kullanıcı deneyimi yaratır. Graceful shutdown yeni connection kabulünü durdururken mevcut stream’lerin belirli süre tamamlanmasına izin verir. Kubernetes termination grace period bu davranışla uyumlu ayarlanmalıdır. Çok uzun stream sonsuza kadar deployment’ı bloke etmemelidir. Maksimum grace period sonunda kalan connection kontrollü biçimde kapatılabilir.

Deployment Sırasında Aktif Stream'ler

Pod terminate olmadan önce aktif stream sayısı bilinmelidir. Readiness false yapılarak yeni trafik kesilir. Mevcut connection çalışmaya devam eder. Metrics drain süresini gösterir. User request mümkünse tamamlanır.

Yeni Connection Kabulünü Durdurmak

Instance load balancer pool’dan çıkarılır. Readiness endpoint false döner. Yeni request başka node’a gider. Existing sockets açık kalır. Bu aşama shutdown sinyali alındığında hemen başlamalıdır.

Mevcut Stream'leri Tamamlamak

Aktif stream’lere grace period verilir. Normal done event gönderilir. Tool execution güvenli şekilde tamamlanır. Çok uzun agent task asenkron sisteme devredilebilir. Shutdown metric’leri izlenir.

Maksimum Grace Period

Deployment sonsuza kadar beklememelidir. Maksimum süre tanımlanır. Süre aşan stream error event alabilir. Client retry seçeneği sunar. Uzun stream pattern’i product design açısından incelenebilir.

Kubernetes Termination Grace Period

Kubernetes SIGTERM sonrası belirli süre bekler. Application bu sinyali yakalamalıdır. Readiness hızla false olmalıdır. Grace period tipik stream süresinden uzun seçilebilir. Force kill öncesi cleanup tamamlanmalıdır.

Kullanıcıya Kesintisiz Deployment Sunmak

Yeterli replica sayısı gerekir. Rolling update sırasında capacity korunmalıdır. Connection draining doğru çalışmalıdır. Sticky state problem yaratmamalıdır. Deployment load test ile doğrulanmalıdır.

Uzun Süren AI İşleri HTTP İsteğinde Bekletilmeli mi?

Her AI işi streaming connection üzerinde tutulmamalıdır. Saniyeler içinde tamamlanan chat request için senkron veya streaming model uygundur. Dakikalar süren belge işleme veya batch generation için asenkron job daha güvenilir olabilir. Queue ve worker sistemi request lifecycle’dan bağımsız çalışır. Client Job ID üzerinden status sorgulayabilir veya sonuç webhook ile başka sisteme bildirilebilir.

Senkron İşler

Kısa işlemler HTTP request süresinde tamamlanabilir. Kullanıcı sonucu hemen bekler. Timeout sınırı nettir. Implementation basittir. Çok uzun süren görevler bu modele zorlanmamalıdır.

Asenkron İşler

Server request’i kabul eder ve Job ID döndürür. İş arka planda worker tarafından çalıştırılır. Kullanıcı bağlantısının açık kalması gerekmez. Retry daha kontrollü yapılır. Progress ayrı endpoint veya event kanalından sunulabilir.

Job Queue

Queue pending işleri saklar. Worker kapasitesi bağımsız ölçeklenir. Priority uygulanabilir. Message visibility timeout doğru ayarlanmalıdır. Duplicate delivery için idempotent worker gerekir.

Worker

Worker job’ı queue’dan alır. AI provider çağrısını yapar. Result database veya object storage’a yazar. Failure retry policy uygular. Long-running task health ayrıca izlenmelidir.

Job ID

Job ID istemcinin işlemi takip etmesini sağlar. UUID kullanılabilir. Kullanıcı yalnızca kendi Job ID’sine erişebilmelidir. Idempotency key ile ilişkilendirilebilir. Log correlation için kullanışlıdır.

Status Endpoint

Client Job ID ile status sorgular. pending, running, completed veya failed dönebilir. Progress yüzdesi iş tipine göre verilebilir. Çok sık polling rate limit uygulanabilir. Completed result referansı eklenir.

Polling

Client belirli aralıklarla status endpoint çağırır. Basit implementation sunar. Çok sık polling gereksiz trafik oluşturur. Exponential interval kullanılabilir. Uzun işler için webhook veya SSE daha verimli olabilir.

Webhook

Server iş bitince callback endpoint’e POST yapar. Server-to-server entegrasyon için uygundur. Payload signature ile doğrulanmalıdır. Retry idempotent olmalıdır. Browser client webhook endpoint değildir.

Dead Letter Queue

Belirli sayıda başarısız job DLQ’ya gider. Operasyon ekibi root cause inceler. İş kaybolmaz. Manual veya otomatik replay yapılabilir. Poison message sonsuz retry döngüsüne girmemelidir.

Polling, SSE, WebSocket ve Webhook Karşılaştırması

Bu iletişim yöntemleri farklı problem tiplerine yöneliktir. Polling en basit yaklaşımdır ancak sürekli request oluşturur. SSE server’dan client’a canlı progress ve token akışı için uygundur. WebSocket sürekli çift yönlü iletişimi destekler. Webhook ise server-to-server asenkron completion bildiriminde güçlüdür.

Polling

Client belirli aralıklarla yeni veri sorar. HTTP altyapısı basittir. Gerçek zamanlılık interval’a bağlıdır. Gereksiz boş request oluşabilir. Asenkron job status için yeterli olabilir.

Long Polling

Server veri gelene kadar request’i açık tutar. Event oluşunca response döner. Client hemen yeni request açar. SSE’den daha fazla connection churn oluşabilir. Legacy uyumluluk gerektiğinde kullanılabilir.

SSE

SSE sürekli server-to-client event akışı sağlar. Chat streaming için güçlüdür. HTTP altyapısıyla uyumludur. Reconnect desteği eklenebilir. Client sürekli veri gönderecekse sınırlı kalır.

WebSocket

WebSocket iki yönlü kalıcı bağlantı sağlar. Voice ve realtime control için uygundur. Connection state yönetimi gerekir. Proxy configuration daha fazla dikkat ister. Basit token stream için gereksiz olabilir.

Webhook

Webhook asenkron işin sonucunu başka server’a iletir. Client polling ihtiyacını azaltır. Endpoint publicly reachable olabilir. Signature verification gerekir. Retry ve idempotency zorunludur.

Hangi Senaryoda Hangisi?

Kısa job status için polling seçilebilir. Chat token akışı için SSE değerlendirilmelidir. Voice ve full-duplex sistemde WebSocket veya WebRTC uygundur. Server-to-server completion için webhook kullanışlıdır. Gereksinimden daha karmaşık protokol seçilmemelidir.

Multimodal AI'da Ağ İletişimi

Multimodal AI metin dışında görsel, ses ve video verisi işler. Bu içerikler request boyutunu ciddi biçimde artırabilir. Büyük dosyaları application backend üzerinden geçirmek network ve memory yükünü artırır. Object storage ve presigned URL yaklaşımı daha ölçeklenebilir olabilir. Dosya güvenliği ve içerik doğrulaması upload pipeline’ın parçası olmalıdır.

Metin

Metin payload genellikle küçük boyutludur. JSON içinde rahat taşınır. Token sayısı yine sınırlandırılmalıdır. Compression çoğu zaman önemli olabilir. Hassas prompt loglanmamalıdır.

Görsel

Görseller birkaç MB olabilir. Base64 JSON payload boyutunu artırır. Multipart veya object storage daha verimlidir. Image dimension ve file type doğrulanmalıdır. Malware veya steganography riski kullanım alanına göre değerlendirilmelidir.

Ses

Ses batch veya stream olarak gönderilebilir. Realtime voice için WebSocket veya WebRTC uygundur. Kayıt dosyası için object storage kullanılabilir. Codec bandwidth üzerinde doğrudan etkilidir. PII ve biometric data politikası ayrıca değerlendirilmelidir.

Video

Video çok büyük veri üretir. Backend memory üzerinden geçirmek verimsizdir. Object storage upload tercih edilir. AI processing asenkron job olabilir. Progress SSE veya polling ile gösterilebilir.

Büyük Request Payload'ları

Büyük body proxy limitine takılabilir. Upload süresi timeout yaratabilir. Memory buffering engellenmelidir. Streaming upload veya object storage tercih edilebilir. Request size limit güvenlik açısından zorunludur.

Multipart Upload

Multipart form text ve file alanlarını birlikte taşıyabilir. Backend dosyayı disk veya stream olarak işleyebilir. Büyük dosyada memory’ye tamamını almamak gerekir. File type doğrulanmalıdır. Reverse proxy body size ayarı uygun olmalıdır.

Object Storage

Client dosyayı doğrudan object storage’a gönderebilir. Backend bandwidth tüketmez. Upload sonrası object ID AI job’a verilir. Access private tutulmalıdır. Lifecycle policy gereksiz dosyaları temizler.

Presigned URL Yaklaşımı

Backend kısa ömürlü upload URL üretir. Client doğrudan storage’a yükler. Credential client’a verilmez. URL object ve size scope ile sınırlandırılmalıdır. Upload tamamlanınca backend doğrulama yapar.

Büyük Dosyalar AI Sistemlerine Nasıl Gönderilmeli?

Büyük dosyaların application backend üzerinden geçirilmesi ilk bakışta kolaydır ancak yüksek trafikte darboğaz oluşturabilir. Presigned URL ile doğrudan object storage upload daha ölçeklenebilir bir modeldir. Upload tamamlandıktan sonra backend dosyayı virüs ve format kontrolünden geçirir. Çok büyük dosyalarda chunked ve resume edilebilir upload kullanıcı deneyimini iyileştirir. File size limitleri hem güvenlik hem maliyet için zorunludur.

Dosyayı Backend Üzerinden Geçirmek

Client dosyayı backend’e upload eder. Backend daha sonra storage’a yazar. Network trafiği iki katına çıkabilir. Server memory veya disk yükü artar. Küçük dosyalarda yine yeterli olabilir.

Doğrudan Object Storage Upload

Client storage endpoint’e doğrudan bağlanır. Backend yalnızca izin üretir. Application server bandwidth tüketimi azalır. Upload policy object key ile sınırlandırılır. Sonrasında processing job tetiklenebilir.

Presigned URL

URL kısa süre için geçerlidir. Belirli HTTP method’a izin verir. Object path sabitlenebilir. Expired URL yeniden kullanılmaz. Client secret credential bilmez.

Chunked Upload

Dosya parçalara ayrılır. Her chunk ayrı yüklenebilir. Network kesintisinde tüm dosya baştan başlamaz. Server veya storage parçaları birleştirir. Chunk checksum doğrulanabilir.

Resume Edilebilir Upload

Client tamamlanan chunk listesini saklar. Connection koptuğunda kaldığı yerden devam eder. Mobil kullanıcılar için faydalıdır. Upload session ID gerekir. Expired session cleanup edilmelidir.

Dosya Boyutu Limitleri

Sınırsız upload DDoS riskidir. Tenant planına göre limit uygulanabilir. Proxy ve storage limitleri uyumlu olmalıdır. Client kullanıcıya limiti önceden göstermelidir. Aşım durumunda 413 benzeri hata döndürülebilir.

Virüs ve İçerik Kontrolü

Upload edilen dosya güvenilir kabul edilmemelidir. Malware scan yapılabilir. MIME type yalnızca filename’e göre belirlenmemelidir. Parsing sandbox içinde çalıştırılabilir. Temiz olmayan dosya AI pipeline’a alınmamalıdır.

AI Client-Server İletişiminde Güvenlik

AI istemci-sunucu güvenliği klasik web güvenliğinin üzerine maliyet ve model erişim risklerini ekler. HTTPS tüm trafiği şifrelemelidir. Kullanıcı authentication OAuth, JWT veya session üzerinden yapılabilir. Provider API key backend’de tutulmalı ve düzenli rotate edilmelidir. Least privilege hem kullanıcı hem servis kimliklerinde uygulanmalıdır.

HTTPS/TLS

Tüm production trafiği TLS ile korunmalıdır. Plain HTTP üzerinden prompt gönderilmemelidir. Certificate expiry izlenmelidir. Internal service bağlantıları da mümkün olduğunca şifrelenmelidir. Modern TLS configuration kullanılmalıdır.

API Key

API key application veya provider kimliği için kullanılabilir. Frontend içine gömülmemelidir. Secret manager içinde saklanmalıdır. Scope minimum tutulmalıdır. Rotation otomatikleştirilebilir.

OAuth 2.0

OAuth delegated authorization için yaygın standarttır. User login ile API access ayrılabilir. Access token kısa ömürlü tutulabilir. Refresh token daha güvenli storage gerektirir. Scope AI feature erişimini sınırlayabilir.

JWT

JWT signed identity claim taşıyabilir. Server signature ve expiration doğrulamalıdır. Payload gizli değildir. Hassas secret içine konmamalıdır. Key rotation ve issuer validation gereklidir.

Session Cookie

Web uygulamasında secure session cookie kullanılabilir. HttpOnly XSS riskini azaltır. Secure flag TLS zorunlu kılar. SameSite CSRF riskini yönetmeye yardımcı olur. Session store multi-instance backend’de paylaşılabilir.

Short-Lived Token

Kısa ömürlü token sızıntı etkisini azaltır. Long-running WebSocket session için refresh davranışı tanımlanmalıdır. Token query string içinde taşınmamalıdır. Backend expiration kontrolü yapmalıdır. Machine identity için ayrı credential kullanılmalıdır.

Secret Rotation

Provider key belirli aralıklarla değiştirilmelidir. Yeni ve eski key kısa overlap döneminde birlikte çalışabilir. Deployment kesintisi önlenir. Eski key hızla revoke edilir. Rotation audit kaydına alınmalıdır.

Least Privilege

Frontend kullanıcı tokenı yalnızca gerekli endpoint’lere erişmelidir. Backend provider key minimum model scope’una sahip olabilir. Tool service account ayrı izin kullanmalıdır. Admin credential application runtime’a verilmemelidir. Access review düzenli yapılmalıdır.

CORS, CSRF ve WebSocket Güvenliği

Browser tabanlı AI istemcilerinde CORS ve CSRF klasik güvenlik konuları olmaya devam eder. Streaming kullanılması bu riskleri ortadan kaldırmaz. Allowed origin listesi açıkça tanımlanmalıdır. WebSocket handshake sırasında Origin header doğrulanmalıdır. Token’ın query string’e eklenmesi proxy ve loglarda credential sızıntısı yaratabilir.

CORS Nedir?

CORS browser’ın farklı origin request kurallarını belirler. Server hangi origin’lere izin verdiğini header ile bildirir. Wildcard kullanımı credential request’lerinde riskli olabilir. Preflight request desteklenmelidir. CORS authentication değildir.

Allowed Origins

Production domain açık listede tutulmalıdır. Development localhost ayrı configuration olabilir. Kullanıcı tarafından gönderilen Origin doğrudan echo edilmemelidir. Dynamic tenant domain varsa doğrulama gerekir. Subdomain wildcard dikkatle kullanılmalıdır.

CSRF

Cookie tabanlı authentication CSRF riskine açıktır. State-changing request token kontrolü gerektirebilir. SameSite cookie yardımcı olur. Origin ve Referer kontrolü ek katmandır. AI request de maliyet yarattığı için CSRF önemlidir.

SameSite Cookie

SameSite browser’ın cross-site cookie gönderimini sınırlar. Lax veya Strict birçok uygulamada güvenlik sağlar. Cross-site gereksinim varsa None ve Secure gerekir. Authentication akışı test edilmelidir. Mobile webview davranışı farklı olabilir.

WebSocket Origin Validation

WebSocket CORS mekanizmasını aynı şekilde kullanmaz. Server Origin header doğrulamalıdır. Authentication token ayrıca kontrol edilir. Cross-site malicious page connection açamamalıdır. Allowed origin listesi merkezi tutulmalıdır.

Token'ı Query String'e Koymanın Riskleri

Query string proxy loglarına yazılabilir. Browser history veya analytics sistemine sızabilir. WebSocket için header kullanımı client API nedeniyle zor olabilir. Short-lived one-time token alternatifi değerlendirilebilir. URL içindeki token minimum süre geçerli olmalıdır.

Rate Limiting ve Abuse Prevention

AI servislerinde abuse yalnızca trafik yoğunluğu değil doğrudan maliyet artışı anlamına gelir. Klasik IP rate limit tek başına yeterli değildir. Kullanıcı, tenant, token tüketimi ve concurrent stream sayısı birlikte sınırlandırılabilir. Budget kontrolü belirli dönemde toplam maliyeti korur. Uzun bağlantılar için connection limiti ayrı metric olarak uygulanmalıdır.

IP Bazlı Rate Limit

Aynı IP’den aşırı istek engellenebilir. NAT arkasında birçok kullanıcı olabilir. Bu nedenle tek başına yeterli değildir. Bot saldırılarında faydalıdır. IPv6 range davranışı ayrıca düşünülmelidir.

Kullanıcı Bazlı Rate Limit

Authenticated user üzerinden quota uygulanır. Farklı abonelik planları farklı limite sahip olabilir. Shared IP problemi azalır. Account takeover yine risk oluşturur. Anormal kullanım alarm üretebilir.

Tenant Bazlı Rate Limit

Kurumsal müşterinin toplam kullanımı sınırlandırılır. Bir kullanıcı tenant kapasitesinin tamamını tüketmemelidir. User ve tenant limit birlikte uygulanabilir. Shared budget oluşturulabilir. Admin dashboard kullanım gösterebilir.

Token Bazlı Limit

Request sayısı maliyeti tam yansıtmaz. Uzun prompt çok daha pahalı olabilir. Input ve output token quota hesaplanabilir. Request başlamadan tahmini budget kontrolü yapılabilir. Completion sonrası gerçek kullanım güncellenir.

Concurrent Stream Limiti

Kullanıcı aynı anda sınırsız chat stream açmamalıdır. Her connection backend resource tutar. Belirli sayı sonrası yeni request reddedilebilir. Eski connection disconnect ise sayaç temizlenmelidir. Race condition distributed rate limiter ile yönetilmelidir.

Connection Limiti

IP veya tenant başına açık bağlantı sınırı konabilir. Slowloris benzeri risk azalır. WebSocket ve SSE ayrı sayılabilir. Idle connection kısa sürede kapatılır. Edge ve backend limitleri uyumlu olmalıdır.

Cost Budget

Aylık veya günlük maliyet tavanı belirlenebilir. Model bazlı farklı ağırlık kullanılabilir. Budget yaklaşınca warning gönderilir. Aşımda daha küçük modele routing yapılabilir. Kritik uygulamalar için ayrı emergency budget tanımlanabilir.

DDoS ve Connection Exhaustion

Uzun süre açık kalan SSE ve WebSocket connection’ları DDoS tasarımında özel önem taşır. Saldırgan çok sayıda connection açarak file descriptor ve memory tüketebilir. Maximum connection per user ve idle timeout bu riski azaltır. WAF ve edge rate limiting zararlı trafiği origin’e ulaşmadan kesebilir. Circuit breaker downstream model servisinin aşırı yüklenmesini önleyebilir.

Uzun Açık Bağlantıların Riski

Her connection server kaynağı tüketir. Saldırgan düşük trafikle çok socket açık tutabilir. RPS metriği sorunu göstermeyebilir. Active connection metriği izlenmelidir. Idle timeout uygulanmalıdır.

Maximum Connection per User

Authenticated user’a connection limiti verilir. Aynı account abuse engellenir. Mobile reconnect sırasında eski connection kısa süre açık kalabilir. Grace period dikkate alınmalıdır. Limit distributed state ile takip edilebilir.

Idle Connection Timeout

Hiç veri alışverişi olmayan connection kapatılır. Heartbeat normal bağlantıyı canlı tutar. Timeout çok uzun olmamalıdır. Çok kısa değer mobile network sorunlarında gereksiz kopma yaratır. Proxy ve app aynı policy’ye sahip olmalıdır.

Request Size Limit

Devasa prompt memory ve token maliyeti oluşturur. HTTP body limit uygulanmalıdır. File upload ayrı endpoint olmalıdır. Tokenization sonrası context limiti tekrar kontrol edilir. Aşım kullanıcıya anlaşılır biçimde bildirilir.

WAF

WAF bilinen kötü trafik kalıplarını engelleyebilir. Bot rule ve IP reputation kullanılabilir. AI prompt içeriğini klasik SQL injection gibi yorumlamak her zaman doğru değildir. False positive test edilmelidir. WAF logging sensitive body içermemelidir.

Edge Rate Limiting

Rate limit mümkün olduğunca edge’de başlayabilir. Origin kaynakları korunur. Global counter platform tarafından yönetilebilir. Authentication sonrası user limit backend’de devam eder. Multi-layer limit birbirine zıt olmamalıdır.

Circuit Breaker

Model provider aşırı hata veriyorsa yeni request kesilebilir. Böylece thread ve connection birikmez. Fallback model devreye girebilir. Half-open probe recovery’yi test eder. Threshold burst traffic’te yanlış açılmamalıdır.

Kullanıcı Verileri Ağ Üzerinden Nasıl Korunmalı?

AI request’leri çoğu zaman klasik API trafiğinden daha hassas içerik taşır çünkü kullanıcı serbest metin içinde kişisel veya kurumsal bilgi yazabilir. TLS transit güvenliğinin temelidir. Bunun yanında proxy, gateway ve observability logları hassas içeriği yanlışlıkla saklayabilir. PII redaction ve sensitive header filtering bu riski azaltır. Data residency kuralları telemetry ve backup akışına kadar değerlendirilmelidir.

TLS

Client ve backend bağlantısı şifrelenmelidir. Backend-provider bağlantısı da TLS kullanmalıdır. Internal network güvenilir kabul edilmemelidir. Certificate validation kapatılmamalıdır. Expiry monitoring yapılmalıdır.

PII Redaction

Prompt loglanmadan önce kişisel veri maskelenebilir. Telefon ve kimlik gibi alanlar tespit edilebilir. False negative riski vardır. En güvenlisi ihtiyaç yoksa body loglamamaktır. Redacted veri yine access policy’ye tabi olmalıdır.

Sensitive Header Filtering

Authorization ve cookie header loglardan çıkarılmalıdır. Provider API key asla trace attribute olmamalıdır. Reverse proxy default log formatı kontrol edilmelidir. Error dump header’ları içerebilir. Secret scanning log pipeline’da uygulanabilir.

Prompt Logging Riski

Debug için prompt loglamak caziptir. Ancak zamanla hassas veri deposu oluşur. Access ve retention yönetmek gerekir. Metadata-only logging daha güvenlidir. Sampling gerektiğinde explicit opt-in uygulanabilir.

Response Logging Riski

Model çıktısı da kişisel veya gizli veri içerebilir. Full response log default olmamalıdır. Evaluation için örnekler anonimleştirilebilir. Security incident dışında ham içerik erişimi sınırlandırılmalıdır. Log export destination kontrol edilmelidir.

Proxy ve Gateway Loglarında Hassas Veriler

Gateway request body capture özelliği kapalı tutulabilir. Query string hassas token içermemelidir. Header mask uygulanmalıdır. Debug mode production’da sürekli açık bırakılmamalıdır. Log retention merkezi policy ile yönetilmelidir.

Data Residency

Request ve telemetry farklı region’lara gidebilir. Harici provider data processing region incelenmelidir. CDN log lokasyonu da önemlidir. Backup ve observability platformu aynı değerlendirmeye dahildir. Mimari data flow dokümanı bu bilgiyi göstermelidir.

AI Ağ Trafiğinde Observability

AI ağ trafiği klasik request metric’lerinin yanında stream ve provider bilgilerine ihtiyaç duyar. Structured logging sorgulanabilir event kayıtları üretir. Distributed tracing client request’inden model provider’a kadar geçen yolu gösterir. OpenTelemetry vendor-neutral bir yaklaşım sağlayabilir. Request ID, Trace ID ve Provider Request ID birlikte tutulduğunda hata analizi önemli ölçüde hızlanır.

Structured Logging

Loglar JSON gibi yapılandırılmış formatta tutulabilir. Request ID ve model adı field olur. Prompt içeriği varsayılan olarak bulunmaz. Error code normalize edilir. SIEM ve search sistemi kolay sorgu yapar.

Metrics

Counter, gauge ve histogram kullanılır. Active connections gauge olabilir. TTFT histogram olarak ölçülebilir. Error rate counter üzerinden hesaplanır. Cardinality kontrol edilmelidir.

Distributed Tracing

Trace tek request’in servisler arasındaki yolunu gösterir. Backend, RAG ve provider ayrı span olur. Network gecikmesi daha görünür hale gelir. Trace sampling maliyet kontrolü sağlar. Sensitive attribute maskelenmelidir.

OpenTelemetry

OpenTelemetry ortak tracing ve metric standardı sunar. Farklı vendor backend’lerine export yapılabilir. HTTP client auto-instrumentation faydalıdır. LLM-specific semantic convention gelişebilir. Custom attribute tasarımı düşük cardinality olmalıdır.

Request ID

Her HTTP çağrısına benzersiz ID verilir. Client response header’da görebilir. Support ticket bu ID’yi kullanabilir. Retry yeni request ID alabilir. Logical idempotency key ayrı tutulur.

Correlation ID

Birden fazla request aynı kullanıcı işlemine ait olabilir. Correlation ID bunları gruplayabilir. Agent tool çağrıları aynı correlation altında olabilir. Client ve server logları eşleşir. Guessable hassas bilgi içermemelidir.

Trace ID

Trace ID distributed tracing sisteminin ana anahtarıdır. Tüm span’lar aynı trace altında bağlanır. Browser’dan backend’e aktarılabilir. Harici provider aynı trace standardını desteklemeyebilir. Provider ID ayrı field olarak tutulur.

Provider Request ID

LLM provider her çağrı için kendi ID’sini verebilir. Support ticket açarken değerlidir. Backend request ID ile eşleştirilmelidir. Retry farklı provider request ID üretir. Maliyet ve hata analizi bu ilişkiyi kullanabilir.

İzlenmesi Gereken Network ve AI Metrikleri

Production AI sisteminde yalnızca toplam request sayısı izlemek yeterli değildir. Active connection, connection duration ve stream completion rate kullanıcı deneyimini daha doğrudan gösterir. TTFT ve inter-token latency model ile network performansını ayırmaya yardımcı olur. Client disconnect ve cancellation rate ürün davranışına dair değerli sinyal sağlar. Cost per request ise teknik performansı ekonomik sonuçla ilişkilendirir.

Request Rate

Saniye veya dakika başına request sayısı ölçülür. Endpoint bazında ayrılabilir. Chat ve embedding workload farklıdır. Peak trafik capacity planına girer. Rate tek başına stream concurrency’yi göstermez.

Error Rate

4xx ve 5xx ayrı izlenmelidir. Provider error başka category olabilir. Stream içi error HTTP status’a yansımayabilir. Typed error event metric oluşturmalıdır. Sudden spike alarm üretir.

Active Connections

Anlık açık SSE ve WebSocket connection sayısıdır. Capacity planning için kritiktir. User ve tenant bazında dağılım görülebilir. Node bazlı imbalance load balancer sorununu gösterebilir. Autoscaling sinyali olabilir.

Connection Duration

Her stream’in ne kadar açık kaldığını ölçer. P95 değer önemlidir. Çok uzun connection runaway generation gösterebilir. Voice session chat stream’den farklı baseline’a sahiptir. Endpoint bazlı izlenmelidir.

TTFT

İlk token latency’sidir. P50 ve P95 takip edilir. Retrieval veya provider queue problemi burada görünür. Cache hit request ayrı sınıflandırılabilir. User experience için ana metric’tir.

Inter-Token Latency

Tokenlar arası akış hızını gösterir. Jitter kullanıcıya takılma olarak yansır. Provider veya network problemi olabilir. Client buffering metric’i etkileyebilir. Raw server ve client ölçümü karşılaştırılmalıdır.

Stream Completion Rate

Başlayan stream’lerin kaçının done event ile tamamlandığını gösterir. Disconnect ve error oranını görünür kılar. Düşük oran production problemine işaret eder. Mobile ve desktop ayrı segmentlenebilir. Provider bazlı fark incelenebilir.

Client Disconnect Rate

Kullanıcı veya network kaynaklı kapanmaları ölçer. Çok yüksek oran latency problemine işaret edebilir. Mobile network daha yüksek olabilir. Stop button cancellation ayrı tutulmalıdır. Disconnect sonrası upstream cancel başarısı ölçülebilir.

Cancellation Rate

Kullanıcıların ne kadar sık stop verdiğini gösterir. Çok uzun veya düşük kaliteli cevap sinyali olabilir. Product feature bazında ölçülebilir. Cancellation maliyet tasarrufu hesaplanabilir. Yanlışlıkla cancel teknik problemden ayrılmalıdır.

Retry Rate

Request’lerin kaç kez tekrar denendiğini gösterir. Yüksek oran provider instability belirtisidir. Client ve backend retry ayrı izlenmelidir. Duplicate cost riski vardır. Retry budget ihlali alarm üretebilir.

Upstream Timeout Rate

Provider veya model server timeout oranıdır. Capacity saturation gösterebilir. Region bazlı network sorunu olabilir. Model bazında farklı baseline vardır. Fallback oranıyla birlikte izlenmelidir.

Tokens per Second

Generation throughput değeridir. Model ve hardware performansını gösterir. Client tarafında algılanan hız farklı olabilir. Concurrent load arttıkça değişebilir. Quantization ve batching benchmark’ında kullanılır.

Cost per Request

Token ve provider fiyatından hesaplanabilir. Self-hosted sistemde GPU maliyeti dağıtılabilir. Feature ve tenant bazında raporlanabilir. Cache hit maliyeti düşürür. Anormal artış prompt length sorununu gösterebilir.

Client-Server İletişimi Nasıl Debug Edilir?

AI streaming hatalarını debug ederken browser’dan provider’a kadar katmanları sırayla incelemek gerekir. Browser Network Panel request ve stream davranışını gösterir. SSE chunk veya WebSocket frame seviyesinde veri akışı kontrol edilebilir. TTFT ve chunk aralıkları proxy buffering sorunlarını görünür kılar. Trace ID ile aynı request backend loglarında takip edilmelidir.

Browser Network Panel

Request URL ve timing bilgisi görülebilir. Response streaming davranışı izlenir. Header ve status kontrol edilir. Connection uzun süre pending görünmesi normal olabilir. DevTools production sorunlarını hızlı doğrular.

Request Headers

Authorization header doğru mu kontrol edilir. Content-Type request formatıyla eşleşmelidir. Trace header gönderilebilir. WebSocket upgrade header proxy tarafından korunmalıdır. Sensitive token ekran görüntüsünde paylaşılmamalıdır.

Response Headers

Content-Type SSE için text/event-stream olmalıdır. Cache-Control kontrol edilir. Proxy-specific buffering header incelenebilir. CORS header browser erişimini etkiler. Server timing ek observability sağlayabilir.

HTTP Status

Stream başlamadan hata varsa status bilgi verir. 401 authentication problemidir. 429 rate limit gösterir. 502 upstream veya proxy sorunu olabilir. Stream başladıktan sonraki error in-band gelir.

SSE Chunk'ları

Event satırları tek tek incelenebilir. Chunk’ların gecikmeli toplu geldiği görülebilir. Event ID sırası kontrol edilir. Parser format hatası tespit edilir. done event gelip gelmediği önemlidir.

WebSocket Frame'leri

DevTools text ve binary frame’leri gösterebilir. Ping/pong davranışı incelenir. Unexpected close code tespit edilir. Client ve server message sequence karşılaştırılır. Büyük frame pattern’i performans sorunu yaratabilir.

TTFT

Request başlangıcı ve ilk stream byte zamanı ölçülür. Backend trace ile karşılaştırılır. Provider ilk token hızlıysa proxy buffer ediyor olabilir. Retrieval latency yüksek olabilir. Metric root cause daraltır.

Chunk Aralıkları

Token chunk’ları arasındaki süre incelenir. Düzenli büyük aralık buffering belirtisi olabilir. Provider hızlı ama client yavaşsa network veya render sorunu vardır. Server timestamp event metadata’ya geçici eklenebilir. Production’da gereksiz ayrıntı tutulmamalıdır.

Stream Completion

Connection normal done event ile kapanıyor mu kontrol edilir. Abrupt EOF network sorunu gösterebilir. Client abort ile server error ayrılmalıdır. Finish reason loglanmalıdır. Partial response state incelenmelidir.

Trace ID ile Backend Takibi

Client response header’daki Trace ID support ekibine iletebilir. Backend log ve span’lar aynı ID ile aranır. Provider request ID bulunur. Hangi katmanda gecikme olduğu görülür. Debug süresi ciddi biçimde kısalır.

"Localhost'ta Çalışıyor, Production'da Çalışmıyor" Problemi

AI streaming projelerinde localhost ile production arasındaki fark çoğunlukla model kodundan değil ağ katmanlarından kaynaklanır. Local ortamda CDN, WAF, reverse proxy veya load balancer olmayabilir. Production’da buffering ve timeout devreye girer. CORS ve HTTPS kuralları browser davranışını değiştirir. WebSocket upgrade ve sticky session ayarları özellikle dağıtık ortamda ayrıca test edilmelidir.

Reverse Proxy Buffering

Local backend doğrudan browser’a stream eder. Production proxy response’u buffer edebilir. Tokenlar toplu gelir. Streaming endpoint için buffering kapatılmalıdır. TTFT ve chunk timing testi yapılmalıdır.

CDN Buffering

CDN dynamic response’u optimize etmeye çalışabilir. Stream parçaları birikerek gecikebilir. Platform streaming support incelenmelidir. Cache kapalı olmalıdır. Bypass route test için kullanılabilir.

Load Balancer Timeout

Model uzun süre token üretmezse load balancer connection’ı kapatabilir. Localhost’ta bu katman yoktur. Idle timeout artırılabilir. Heartbeat event kullanılabilir. Değer capacity ve security ile dengelenmelidir.

CORS

Local development proxy CORS sorununu gizleyebilir. Production origin farklıdır. Allowed origin doğru tanımlanmalıdır. Credential request header’ları kontrol edilmelidir. Preflight failure browser console’da görünür.

HTTPS

Production HTTPS kullanır. Mixed content browser tarafından engellenebilir. WebSocket ws yerine wss kullanmalıdır. Certificate chain hatası bağlantıyı keser. Local self-signed davranışı farklı olabilir.

WebSocket Upgrade

Reverse proxy Upgrade header’ı geçirmelidir. HTTP/2 frontend connection farklı davranabilir. Connection header doğru olmalıdır. CDN WebSocket desteği açık olmalıdır. 101 Switching Protocols response kontrol edilir.

Sticky Sessions

Local tek backend instance vardır. Production multi-instance olabilir. State memory’de tutuluyorsa reconnect farklı node’a gider. Session kaybolabilir. Shared state veya affinity gerekir.

Serverless Execution Limitleri

Local process uzun süre çalışabilir. Serverless function timeout olabilir. Streaming response destek kısıtı bulunabilir. Connection kapandığında provider request devam edebilir. Platform limitleri architecture kararına dahil edilmelidir.

Environment-Specific Network Policy

Production VPC egress policy provider erişimini engelleyebilir. DNS resolution farklı olabilir. Firewall WebSocket port veya destination engelleyebilir. Proxy environment variable outbound HTTP davranışını değiştirebilir. Network policy dokümante edilmelidir.

AI Network Failure Testleri

Production öncesinde yalnızca başarılı happy path test etmek yeterli değildir. Yavaş ağ, paket kaybı ve connection reset gibi senaryolar simüle edilmelidir. Provider timeout ve 429 davranışı özellikle retry stratejisini doğrular. Client disconnect sonrası upstream cancellation test edilmelidir. Partial stream failure kullanıcı arayüzünün gerçek hata durumlarında nasıl davrandığını gösterir.

Yavaş Ağ Simülasyonu

Browser veya test proxy bandwidth’i sınırlandırabilir. Stream buffering davranışı görülür. Client render ve backpressure test edilir. Timeout değerleri doğrulanır. Mobile deneyim hakkında fikir verir.

Paket Kaybı

Network emulator paket kaybı oluşturabilir. TCP ve WebRTC davranışı gözlemlenir. Reconnection mekanizması test edilir. Audio quality etkisi ölçülür. Error metric doğru çalışmalıdır.

Connection Reset

Stream ortasında socket zorla kapatılır. Server disconnect tespit etmelidir. Upstream request iptal edilmelidir. Client partial state göstermelidir. Duplicate retry oluşmamalıdır.

Provider Timeout

Fake provider response’u geciktirilebilir. Backend timeout tetiklenir. Fallback davranışı doğrulanır. Stream başladıysa error event gönderilir. Retry budget test edilir.

429 Simulation

Test provider 429 döndürür. Retry-After işlenir. Exponential backoff çalışır. Fallback gerekirse devreye girer. Client sürekli spinner’da kalmamalıdır.

DNS Failure

Provider hostname çözümlenmez hale getirilebilir. Connection timeout davranışı test edilir. Retry sınırlı olmalıdır. Alert network kategorisinde oluşmalıdır. Fallback farklı hostname kullanıyorsa çalışabilir.

Proxy Timeout

Reverse proxy idle timeout kısa ayarlanır. Stream’in nasıl koptuğu gözlemlenir. Keep-alive event doğrulanır. Client error handling test edilir. Production configuration buna göre düzeltilir.

Client Disconnect

Tarayıcı request’i abort eder. Backend active task sayısı hızla düşmelidir. Provider billing metriği incelenir. Cancellation loglanmalıdır. Connection leak oluşmamalıdır.

Partial Stream Failure

Belirli token sonrası provider bağlantısı kesilir. Client partial text tutar. Error event veya EOF davranışı test edilir. Retry UX doğrulanır. Conversation state incomplete olur.

Load Test ve Stress Test

AI backend load testi klasik kısa HTTP request testinden farklıdır. Concurrent SSE ve WebSocket connection’ları gerçek süre boyunca açık tutulmalıdır. Slow client ve connection leak senaryoları memory kullanımını ortaya çıkarır. Graceful shutdown testi deployment güvenliğini doğrular. Test sonucu active connection, TTFT, error rate ve cost metriğiyle birlikte değerlendirilmelidir.

Klasik HTTP Load Test

Embedding veya kısa REST endpoint test edilir. RPS ve latency ölçülür. Connection pool davranışı görülür. Rate limit threshold doğrulanır. AI provider mock kullanılarak backend kapasitesi ayrı ölçülebilir.

Concurrent SSE Connection Testi

Binlerce stream aynı anda açılabilir. Ortalama stream süresi gerçekçi tutulur. Memory ve file descriptor izlenir. Proxy buffering gözlemlenir. Completion rate kaydedilir.

WebSocket Connection Testi

Çok sayıda handshake yapılır. Message rate ve connection state izlenir. Ping/pong overhead ölçülür. Reconnect storm simüle edilir. Load balancer affinity davranışı test edilir.

Uzun Stream Testleri

Normalden uzun generation oluşturulur. Idle timeout ve max duration kontrol edilir. Graceful deployment aynı anda denenebilir. Memory leak belirginleşebilir. Provider cancellation davranışı izlenir.

Slow Client Testi

Client response’u yavaş okur. Server buffer kullanımı gözlemlenir. Backpressure çalışmalıdır. Memory sınırsız büyümemelidir. Connection policy doğru devreye girmelidir.

Connection Leak Testi

Bitmiş request sonrası socket ve task cleanup kontrol edilir. Active connection metriği eski seviyeye dönmelidir. File descriptor artmaya devam etmemelidir. Redis session state expire olmalıdır. Uzun soak test faydalıdır.

Graceful Shutdown Testi

Load altında deploy başlatılır. Yeni connection başka node’a gitmelidir. Mevcut stream mümkün olduğunca tamamlanır. Grace period sonrasında eski pod kapanır. Client error oranı düşük kalmalıdır.

Multi-Provider AI Ağ Mimarisi

Birden fazla model sağlayıcısı kullanan sistemlerde ortak API contract büyük kolaylık sağlar. Provider abstraction istemciyi belirli vendor formatına bağlamaz. Health check ve timeout provider bazında yönetilebilir. Automatic fallback bir provider erişilemez olduğunda hizmet sürekliliğini artırabilir. Circuit breaker ve ayrı connection pool izolasyonu sorunların diğer sağlayıcılara yayılmasını engeller.

Provider Abstraction

Application ortak model interface kullanır. Adapter provider-specific payload üretir. Streaming event normalize edilir. Error code ortak modele dönüştürülür. Provider değişimi client’tan gizlenir.

Tek API Contract

Chat, embedding ve tool çağrıları ortak schema kullanabilir. Capability farkları metadata ile belirtilir. Client provider özel field bilmez. Versioning merkezi yapılır. Contract testleri her adapter için çalıştırılır.

Provider Routing

Request kalite, maliyet veya latency kriterine göre yönlendirilebilir. Data residency route’u sınırlandırabilir. Kullanıcı planı model seçimini etkileyebilir. Canary provider küçük trafik alabilir. Routing kararı loglanmalıdır.

Health Check

Provider endpoint düzenli probe edilebilir. Sadece DNS değil gerçek API erişimi ölçülebilir. Rate limit sonucu health failure sayılmamalıdır. Error trend circuit breaker besleyebilir. Health durumu dashboard’da görünür olmalıdır.

Timeout

Her provider farklı latency profiline sahiptir. Aynı timeout değeri uygun olmayabilir. TTFT ve total timeout ayrı düşünülebilir. Fallback için kalan latency budget hesaplanmalıdır. Çok uzun timeout kullanıcı deneyimini bozar.

Automatic Fallback

Primary provider erişilemezse secondary kullanılabilir. Model davranışı farklı olabilir. Tool ve structured output compatibility test edilmelidir. Hassas data fallback provider’a gönderilmeden policy kontrol edilir. Fallback event observability’ye yazılır.

Circuit Breaker

Arka arkaya failure threshold aşılırsa provider geçici kapatılır. Yeni request hemen secondary’ye gider. Belirli süre sonra probe yapılır. Recovery sonrası trafik kademeli artırılır. False trigger oranı izlenmelidir.

Provider Bazlı Connection Pool

Her provider ayrı socket pool kullanır. Slow provider diğerinin connection kapasitesini tüketmez. TLS ve timeout ayarları farklı olabilir. Pool metric provider tag ile izlenir. Capacity provider concurrency limitine göre belirlenir.

MCP ve AI-Native Client-Server Protokolleri

AI sistemleri yalnızca klasik REST endpoint’leri kullanmak zorunda değildir. Model Context Protocol gibi yaklaşımlar AI uygulamalarının araç ve kaynak keşfini daha standart hale getirmeyi amaçlar. MCP client belirli server’ın sunduğu tool ve resource bilgilerini alabilir. Transport katmanı JSON-RPC tabanlı mesajları taşıyabilir. Güvenlik ve authorization yine protokolün dışında açık biçimde tasarlanmalıdır.

Model Context Protocol Nedir?

MCP AI uygulaması ile tool veya data server arasında standart etkileşim modeli sunar. Capability discovery yapılabilir. Tool schema istemci tarafından öğrenilebilir. Resource erişimi ortak format kullanabilir. Protocol kullanmak otomatik authorization sağlamaz.

MCP Client

MCP client host uygulama içinde çalışabilir. Server capability listesini alır. Tool çağrısı gönderir. Response model orchestration’a aktarılır. User authorization context korunmalıdır.

MCP Server

MCP server belirli tool ve resource’ları yayınlar. Her tool açık schema tanımlar. Credential server tarafında güvenli tutulur. Client identity doğrulanabilir. High-risk operation ayrı approval isteyebilir.

Tool Discovery

Client server’ın desteklediği tool listesini sorgular. Tool metadata açıklama ve input schema içerir. Model hangi tool’u kullanacağını bu bilgiyle seçebilir. Approved tool list policy ile sınırlandırılmalıdır. Dynamic discovery güvenilmeyen server’a açılmamalıdır.

Resource Access

Server doküman veya başka kaynak sunabilir. Kullanıcı yetkisi her resource isteğinde kontrol edilmelidir. Resource URI tahmin edilerek erişim sağlanmamalıdır. Data minimization uygulanmalıdır. Audit hangi resource’un kullanıldığını kaydedebilir.

JSON-RPC

JSON-RPC request, response ve notification yapısı sunar. Message ID correlation sağlar. Error object standardize edilebilir. Transport’tan bağımsız çalışabilir. Schema validation yine uygulama tarafında yapılmalıdır.

Transport Katmanı

MCP mesajları farklı transport mekanizmalarıyla taşınabilir. Local process veya network bağlantısı kullanılabilir. Security boundary deployment tipine göre değişir. Remote transport TLS gerektirir. Connection lifecycle observability ile izlenmelidir.

Klasik REST API'den Farkı

REST resource-oriented endpoint tasarımına dayanır. MCP AI tool discovery ve invocation için daha belirgin semantics sunar. Her iş için MCP kullanmak zorunlu değildir. Mevcut REST servis wrapper ile MCP tool olarak sunulabilir. Kurumsal mimari gereksiz yeniden yazımdan kaçınmalıdır.

Agent-to-Agent Ağ İletişimi

Çoklu agent sistemlerinde bir agent başka bir agent’a task gönderebilir veya event akışı başlatabilir. Bu yapı klasik mikroservis iletişimine benzer şekilde authentication, timeout ve tracing gerektirir. Agent discovery güvenilir registry üzerinden yapılmalıdır. Uzun süren görevler asenkron queue üzerinden yürütülebilir. Her agent message için correlation ID kullanılması distributed troubleshooting’i kolaylaştırır.

Tek Agent ve Çoklu Agent Mimarisinin Farkı

Tek agent tüm görevi kendi orchestration içinde yürütür. Multi-agent sistem görevleri uzman agent’lara böler. Network hop sayısı artar. Latency ve failure point çoğalır. Gerçek fayda yoksa multi-agent gereksizdir.

Agent Discovery

Agent capability registry tutulabilir. Request uygun agent’a yönlendirilir. Dynamic discovery güvenilir kaynak kullanmalıdır. Capability version metadata önemlidir. Retired agent routing’den çıkarılmalıdır.

Task Mesajları

Agentlar structured task schema kullanmalıdır. Free-form prompt tek contract olmamalıdır. Task ID ve deadline eklenebilir. Idempotency uygulanmalıdır. Sensitive data minimum tutulmalıdır.

Streaming Event'leri

Agent progress typed event olarak aktarılabilir. Parent agent veya client bu event’leri izler. Tool result ve completion ayrılır. Event sequence korunmalıdır. Recursive stream loops engellenmelidir.

Asenkron Agent İşleri

Uzun agent görevi queue üzerinden yürütülebilir. Worker veya agent service sonucu sonra döndürür. Parent task status güncellenir. Timeout ve cancellation propagate edilmelidir. Dead letter policy gerekir.

Authentication

Agent-to-agent request service identity ile doğrulanmalıdır. Shared static key risklidir. mTLS veya short-lived token kullanılabilir. Tool scope least privilege olmalıdır. User delegation context gerekiyorsa güvenli taşınmalıdır.

Distributed Tracing

Trace ID tüm agent zincirinde korunmalıdır. Her agent ayrı span üretir. Tool ve model çağrısı alt span olabilir. Latency bottleneck görünür hale gelir. Prompt içeriği trace attribute olarak zorunlu değildir.

AI İletişiminde Cache Kullanımı

Cache doğru kullanıldığında AI latency ve maliyetini azaltabilir. Exact response cache aynı request için doğrudan sonuç döndürebilir. Semantic cache benzer anlamdaki soruları eşleştirebilir. Kullanıcıya özel verilerde cache key authorization context içermelidir. Streaming response cache edilecekse final response veya event sequence saklama stratejisi açıkça belirlenmelidir.

Response Cache

Tam response key üzerinden saklanır. Deterministik görevlerde faydalıdır. Model ve prompt version key’e dahil edilmelidir. User-specific response paylaşılmamalıdır. TTL bilgi güncelliğine göre seçilir.

Semantic Cache

Embedding benzerliği kullanır. Aynı anlama gelen sorular cache hit olabilir. Threshold dikkatli seçilmelidir. Yanlış hit yanlış cevap üretir. ACL ve tenant scope key içinde bulunmalıdır.

Edge Cache

Public ve deterministik response edge’de cache edilebilir. Personalized AI cevapları risklidir. Cache-Control doğru ayarlanmalıdır. Streaming dynamic request genellikle bypass edilir. Static model metadata cache için uygundur.

Cache Key Tasarımı

Model version key’e dahil edilmelidir. System prompt version unutulmamalıdır. User veya tenant scope gerekebilir. Retrieval knowledge version cache invalidation sağlar. Temperature gibi generation parametresi de sonucu etkiler.

Kullanıcıya Özel Verilerde Cache Riski

Aynı soru iki kullanıcı için farklı yetkili doküman kullanabilir. Shared cache veri sızıntısı oluşturur. User scope veya ACL hash eklenmelidir. Access değişikliği cache invalidation tetiklemelidir. Hassas response cache dışı bırakılabilir.

Streaming Response Cache Edilebilir mi?

Final response cache edilebilir. Sonraki kullanıcıya yeniden stream etmek için chunk’lara bölünebilir. Gerçek provider TTFT maliyeti ortadan kalkar. Event metadata güncellenmelidir. User-specific stream için izolasyon korunmalıdır.

Client State ve Server State Nasıl Yönetilmeli?

Streaming AI uygulamalarında conversation, message, request ve stream kavramları birbirinden ayrılmalıdır. Conversation ID uzun yaşayan sohbeti temsil eder. Message ID kullanıcı veya assistant mesajını tanımlar. Request ID tek HTTP veya WebSocket işlemine aittir. Server state paylaşılan Redis veya database üzerinde tutulursa multi-instance backend daha kolay ölçeklenir.

Conversation ID

Sohbet oturumunu tanımlar. Birden fazla mesaj aynı conversation’a aittir. Authorization conversation erişimini kontrol etmelidir. Guessable sequential ID tercih edilmemelidir. Retention policy uygulanmalıdır.

Message ID

Her user veya assistant mesajı benzersiz ID alır. Partial assistant response bu ID altında güncellenebilir. Retry yeni generation ID oluşturabilir. Citation ve tool event mesajla ilişkilendirilebilir. UI reconciliation kolaylaşır.

Request ID

Tek network request’i tanımlar. Debug ve tracing için kullanılır. Retry yeni request ID alabilir. Logical message aynı kalabilir. Loglarda response status ile eşleştirilir.

Stream ID

Aktif streaming session’ı tanımlar. Reconnect aynı stream ID kullanabilir. Server active state bulur. Unauthorized user başka stream’e bağlanamamalıdır. Expired stream cleanup edilir.

Server-Side Session

Session kullanıcı state bilgisini server’da tutabilir. Cookie yalnızca session ID taşıyabilir. Multi-instance ortamda shared store gerekir. Expiration ve revocation uygulanmalıdır. Büyük conversation history session store’a doldurulmamalıdır.

Stateless API

Her request gerekli identity ve resource ID taşır. Backend instance local session’a bağımlı değildir. Horizontal scaling kolaydır. Conversation data database’den alınabilir. Çok sık state fetch latency oluşturabilir.

Redis ile Paylaşılan State

Redis active stream ve rate limit state tutabilir. TTL cleanup sağlar. High availability production için önemlidir. Memory kapasitesi izlenmelidir. Redis kalıcı business record yerine geçmemelidir.

Multi-Instance Backend

Load balancer request’i farklı instance’a yönlendirebilir. Shared state consistency gereklidir. WebSocket connection tek node’da kalır. Reconnect başka node’a düşebilir. Distributed locking gerektiğinde dikkatli kullanılmalıdır.

Frontend'de Streaming Response Nasıl Yönetilmeli?

Frontend streaming response’u yalnızca string birleştirerek değil state machine mantığıyla yönetmelidir. message_start, token, tool_call, error ve done gibi event’ler farklı UI davranışı gerektirir. Markdown içerik incremental render edilirken XSS ve partial syntax sorunları dikkate alınmalıdır. Stop ve retry kontrolleri request state ile ilişkilendirilmelidir. Reconnection sırasında duplicate token gösterilmemesi önemlidir.

Incremental Rendering

Yeni chunk geldikçe UI güncellenir. Her karakterde full component render edilmemelidir. Small batching performansı artırabilir. Scroll position korunmalıdır. Final done event state’i tamamlar.

Markdown Streaming

Markdown syntax yarım kalabilir. Parser partial content’i tolere etmelidir. HTML output sanitize edilmelidir. Code block kapanana kadar özel state tutulabilir. Final response yeniden parse edilebilir.

Partial Code Block

Model üç backtick açıp henüz kapatmamış olabilir. Syntax highlighter hata vermemelidir. UI raw fallback gösterebilir. Final chunk sonrası normal render yapılır. Copy button incomplete code için dikkatli davranmalıdır.

Auto Scroll

Yeni token geldikçe chat aşağı kayabilir. Kullanıcı yukarı scroll ettiyse otomatik hareket durmalıdır. Scroll throttling performansı korur. Mobile keyboard state dikkate alınmalıdır. Done event sonrası final position ayarlanabilir.

Stop Button

Aktif request sırasında görünür. AbortController veya WebSocket control event kullanabilir. Buton tekrar tekrar basıldığında duplicate cancel göndermemelidir. Partial text korunabilir. UI status cancelled olur.

Retry

Error veya incomplete message üzerinde sunulabilir. Idempotency veya previous message reference kullanılır. Duplicate assistant message oluşmamalıdır. Kullanıcı retry’nin yeni generation olduğunu görebilir. Old partial response ayrı tutulabilir.

Partial Error State

Stream ortasında error geldiyse mevcut text silinmemelidir. Uyarı mesajı gösterilir. Retry action sunulur. Tool failure ayrı UI olabilir. Accessibility kullanıcıya error state’i duyurmalıdır.

Reconnection State

Network koptuğunda reconnecting durumu gösterilir. User yeni mesaj gönderemeyebilir. Resume başarılıysa stream devam eder. Başarısızsa retry seçeneği çıkar. Duplicate token cursor ile engellenir.

Streaming İçerikte Frontend Güvenliği

Model çıktısı güvenilir HTML olarak kabul edilmemelidir. Markdown parser HTML üretirken sanitization uygulamalıdır. Link ve code block içerikleri farklı güvenlik riskleri taşır. Streaming sırasında partial HTML parse edilmesi XSS riskini artırabilir. Model çıktısına güvenmeme ilkesi frontend tasarımının temel kuralı olmalıdır.

Markdown Sanitization

Markdown HTML’e dönüştürülmeden önce güvenli parser kullanılmalıdır. Raw HTML kapatılabilir. Script ve event handler kaldırılmalıdır. Partial content sanitization ile işlenmelidir. Final render tekrar kontrol edilebilir.

HTML Injection

Model kullanıcı girdisini yansıtabilir. HTML tag doğrudan DOM’a yazılmamalıdır. innerHTML kontrolsüz kullanılmamalıdır. Trusted sanitizer şarttır. CSP ek güvenlik katmanı sağlar.

XSS

Model malicious script üretebilir. RAG dokümanında injected HTML bulunabilir. Output güvenilir source değildir. Browser script execution engellenmelidir. Security test dataset’e XSS örnekleri eklenebilir.

Link Sanitization

javascript: benzeri URL şemaları engellenmelidir. External link yeni tab policy’sine uygun açılmalıdır. rel özellikleri güvenli ayarlanmalıdır. Phishing link kullanıcıya açık gösterilebilir. Citation link whitelist veya validation alabilir.

Code Rendering

Kod metin olarak gösterilmelidir. Otomatik execute edilmemelidir. Preview sandbox gerekiyorsa izole çalışmalıdır. Dangerous shell command için warning verilebilir. Copy işlemi kullanıcı kontrolünde kalmalıdır.

Model Çıktısına Güvenmeme İlkesi

LLM output external input gibi ele alınmalıdır. Schema validation ve sanitization uygulanmalıdır. Tool action server policy’den geçmelidir. HTML escape default olmalıdır. AI üretmiş olması güvenilirlik sağlamaz.

Production-Ready AI Client-Server Referans Mimarisi

Production-ready yapı client’tan model provider’a kadar kontrollü katmanlar içerir. CDN ve WAF dış trafiği filtreler. API Gateway ve BFF authentication, rate limit ve request normalization sağlar. AI Orchestrator model, RAG ve tool akışını yönetir. Redis, queue, database ve observability platformu state, asenkron işler ve operasyon görünürlüğünü destekler.

Web/Mobile Client

Kullanıcı arayüzü request başlatır. Streaming typed event’leri işler. Provider secret taşımaz. Stop ve retry yönetir. Network state kullanıcıya gösterilir.

CDN/WAF

Edge TLS ve DDoS koruması sunar. Static asset cache edilir. Dynamic stream pass-through olabilir. Rate limit ilk katmanda uygulanır. Origin yalnızca edge’den trafik kabul edebilir.

API Gateway

Authentication ve routing merkezi yapılır. Tenant quota uygulanır. Request ID üretilebilir. Circuit breaker provider gateway’i korur. Streaming destek doğrulanmalıdır.

BFF

Client-specific request formatını normalize eder. Session context backend’e taşır. Provider anahtarını gizler. Stream event formatını client’a uygun hale getirir. Business logic minimum tutulur.

Authentication

Identity provider kullanıcı login işlemini yönetir. Short-lived access token kullanılabilir. Role ve tenant bilgisi doğrulanır. Service identity ayrı tutulur. MFA high-risk işlemlerde uygulanabilir.

Rate Limiter

User, tenant ve token quota uygular. Concurrent stream sınırı bulunur. Distributed counter shared store kullanır. Retry-After header döndürülebilir. Cost budget ile entegre çalışır.

AI Orchestrator

Prompt ve context oluşturur. RAG retrieval başlatır. Tool calling güvenli şekilde yönetilir. Model routing yapar. Trace her aşamayı kaydeder.

Provider Gateway

Birden fazla model sağlayıcısını normalize eder. Connection pool yönetir. Timeout ve fallback uygular. Usage bilgisini standardize eder. Provider-specific secret burada saklanır.

LLM Provider

Harici veya kurum içi model olabilir. Streaming inference sağlar. Provider request ID üretir. Rate limit uygulanabilir. Health ve latency metric izlenir.

Redis

Rate limit state tutabilir. Active stream metadata saklayabilir. Short-lived cache sağlar. HA production için önemlidir. Permanent business data burada bırakılmamalıdır.

Queue

Uzun AI task’larını asenkron çalıştırır. Worker scale-out sağlar. Retry ve DLQ mekanizması vardır. Job state database’de tutulabilir. Priority uygulanabilir.

Database

Conversation ve message kayıtlarını saklar. User ve tenant ilişkisi bulunur. Partial state açık biçimde tutulur. Index ve query performansı izlenir. PII retention policy uygulanır.

Observability Platform

Log, metric ve trace toplar. TTFT ve stream completion görünür olur. Cost metriği dashboard’da tutulur. Sensitive content redaction uygulanır. Incident investigation için correlation sağlar.

Örnek Chat İsteğinin Production Akışı

Production akışı küçük adımlara ayrıldığında troubleshooting kolaylaşır. Kullanıcı mesajı HTTPS üzerinden güvenli biçimde backend’e ulaşır. Authentication ve rate limit sonrası request ID üretilir. Context oluşturulur ve LLM upstream request başlatılır. SSE stream typed event formatıyla client’a gelir ve usage bilgisi sonunda kaydedilir.

1. Kullanıcı Mesajı

Kullanıcı chat alanına metin yazar. Frontend local validation yapar. Message ID üretebilir. Stop state sıfırlanır. Request hazırlanmaya başlanır.

2. HTTPS Request

Client backend endpoint’e POST yapar. TLS bağlantıyı korur. Authorization cookie veya header taşınır. Idempotency key eklenir. Request body limit içinde olmalıdır.

3. Authentication

Backend user identity doğrular. Expired token reddedilir. Tenant bilgisi alınır. Authorization context oluşturulur. Trace user ID yerine privacy-safe identifier kullanabilir.

4. Rate Limit

User quota kontrol edilir. Concurrent stream sayısı incelenir. Token budget tahmin edilir. Limit aşılırsa 429 döner. Provider çağrısı yapılmaz.

5. Request ID

Benzersiz request ID üretilir. Response header’a eklenebilir. Log ve trace aynı ID’yi kullanır. Provider request ID daha sonra eşleştirilir. Support troubleshooting kolaylaşır.

6. Context Oluşturma

Conversation history yüklenir. System prompt uygulanır. RAG retrieval yapılabilir. Token budget kontrol edilir. Yetkisiz data context’e eklenmez.

7. LLM Upstream Request

Provider adapter request oluşturur. Shared connection pool kullanılır. Timeout ve cancellation context eklenir. Streaming response istenir. Provider request ID alınır.

8. SSE Stream

Backend text/event-stream header gönderir. message_start event açılır. Token chunk’ları aktarılır. Keep-alive gerekirse gönderilir. Disconnect upstream’e propagate edilir.

9. Typed Event Parsing

Client stream parser event’leri ayırır. token UI’a eklenir. citation ayrı component günceller. error event failure state oluşturur. done stream’i tamamlar.

10. Client Rendering

Text incremental render edilir. Markdown sanitize edilir. Auto scroll kullanıcı davranışına göre çalışır. Stop button aktif kalır. Final event sonrası loading kapanır.

11. Usage Kaydı

Input ve output token sayısı kaydedilir. Provider cost hesaplanabilir. User ve tenant ile ilişkilendirilir. Cancellation varsa partial usage saklanır. Duplicate billing kontrolü yapılır.

12. Observability

Trace tamamlanır. TTFT ve total latency histogram’a eklenir. Stream completion metric güncellenir. Error yoksa success count artar. Quality evaluation ayrı pipeline’da çalışabilir.

Production'a Çıkmadan Önce Network Kontrol Listesi

Production öncesi yalnızca modelin doğru cevap verdiğini kontrol etmek yeterli değildir. TLS, timeout, retry, idempotency ve connection draining davranışları da doğrulanmalıdır. Proxy buffering ve mobile network testleri özellikle streaming uygulamalarında önemlidir. TTFT ve cost monitoring canlıya çıkmadan önce hazır olmalıdır. Bu kontrol listesi operasyon ekibi tarafından release kriteri olarak kullanılabilir.

TLS Aktif mi?

Tüm external trafik HTTPS olmalıdır. WebSocket wss kullanmalıdır. Certificate chain geçerli olmalıdır. Expiration alarmı kurulmalıdır. Internal provider bağlantısı da korunmalıdır.

API Key Frontend'den İzole mi?

Provider key browser bundle içinde olmamalıdır. Backend secret manager kullanmalıdır. Network request’te key görünmemelidir. Rotation test edilmelidir. Leak scanning yapılabilir.

CORS Doğru mu?

Allowed origin listesi production domain’i içermelidir. Wildcard gereksiz kullanılmamalıdır. Credential request test edilmelidir. Preflight başarılı olmalıdır. Development origin production’a taşınmamalıdır.

Rate Limit Var mı?

User ve tenant rate limit uygulanmalıdır. Concurrent stream limiti bulunmalıdır. 429 davranışı client’ta test edilmelidir. Distributed counter doğru çalışmalıdır. Cost budget ayrıca izlenmelidir.

Request Body Limiti Var mı?

Prompt ve file upload limitleri tanımlanmalıdır. Proxy ve app limitleri uyumlu olmalıdır. Aşırı body request erken reddedilmelidir. Token length ayrı kontrol edilir. Kullanıcıya anlaşılır hata dönülmelidir.

Connection Timeout Ayarlandı mı?

Backend-provider connection timeout tanımlanmalıdır. DNS failure sonsuz beklememelidir. Provider bazında değer olabilir. Metric izlenmelidir. Retry policy ile birlikte çalışmalıdır.

Read/Idle Timeout Uyumlu mu?

Proxy ve backend timeout değerleri karşılaştırılmalıdır. Stream heartbeat interval’dan uzun olmalıdır. Çok kısa değer valid stream’i kesmemelidir. Çok uzun değer dead connection tutmamalıdır. Load test ile doğrulanmalıdır.

Proxy Buffering Kapalı mı?

SSE endpoint tokenları anında iletmelidir. Nginx buffering kapatılmalıdır. CDN davranışı ayrıca test edilmelidir. Compression etkisi ölçülmelidir. Browser chunk timing ile doğrulanabilir.

Client Disconnect Upstream'e Aktarılıyor mu?

Browser abort edildiğinde backend task bitmelidir. Provider request kapanmalıdır. Active task metric düşmelidir. Cost gereksiz artmamalıdır. Test otomasyonu bu senaryoyu içermelidir.

Idempotency Var mı?

Retry aynı generation’ı iki kez başlatmamalıdır. Idempotency key uygulanmalıdır. State retention yeterli olmalıdır. Billing aynı key’i dikkate almalıdır. Duplicate test yapılmalıdır.

Duplicate Stream Koruması Var mı?

Aynı logical request ikinci stream açmamalıdır. Active request state kontrol edilmelidir. Reconnect resume veya conflict davranışı belirlenmelidir. Client duplicate token göstermemelidir. Audit duplicate denemeyi kaydetmelidir.

Retry Politikası Var mı?

Retry edilecek hata listesi açık olmalıdır. Backoff ve jitter uygulanmalıdır. Maximum retry sayısı belirlenmelidir. Streaming sonrası retry ayrı ele alınmalıdır. Write tool otomatik retry edilmemelidir.

Graceful Shutdown Test Edildi mi?

Deployment sırasında aktif stream korunmalıdır. Readiness yeni trafiği durdurmalıdır. Grace period yeterli olmalıdır. Node force kill öncesi cleanup yapmalıdır. Client error oranı izlenmelidir.

Load Test Yapıldı mı?

Gerçek concurrency ile test yapılmalıdır. SSE ve WebSocket ayrı test edilmelidir. Slow client senaryosu eklenmelidir. Memory ve file descriptor izlenmelidir. Peak latency kaydedilmelidir.

Mobile Network Test Edildi mi?

Yavaş ağ simülasyonu yapılmalıdır. Wi-Fi ve cellular geçiş test edilmelidir. Reconnect UX doğrulanmalıdır. Partial response korunmalıdır. Duplicate generation oluşmamalıdır.

TTFT İzleniyor mu?

TTFT metric dashboard’da bulunmalıdır. P50 ve P95 gösterilmelidir. Model ve provider bazında ayrılabilir. Regression alert oluşturulabilir. Client ve server ölçümü karşılaştırılmalıdır.

Trace ID Üretiliyor mu?

Her request trace context taşımalıdır. Response header kullanıcıya ID verebilir. Provider request ID ilişkilendirilmelidir. Support log sorgusu yapabilmelidir. Hassas data ID içine gömülmemelidir.

Cost Monitoring Var mı?

Token usage user ve tenant bazında izlenmelidir. Retry maliyeti ayrı görülebilir. Cache tasarrufu ölçülebilir. Budget threshold alarm üretmelidir. Anormal maliyet artışı hızlı tespit edilmelidir.

Sık Yapılan Client-Server AI Mimari Hataları

AI uygulamalarında en sık görülen ağ hataları genellikle model seçiminden bağımsızdır. API key’in frontend’e konması doğrudan güvenlik problemidir. Her kullanım için WebSocket seçmek operasyonu gereksiz büyütür. Proxy buffering ve timeout sorunları streaming deneyimini production’da bozabilir. Client disconnect sonrası modelin çalışmaya devam etmesi de hem maliyet hem kapasite açısından önemli kayıp yaratır.

API Key'i Frontend'e Koymak

Browser içindeki key gizli değildir. Kullanıcı veya saldırgan çıkarabilir. Provider hesabı kötüye kullanılabilir. Backend proxy kullanılmalıdır. Secret rotate edilmelidir.

Her Problem İçin WebSocket Kullanmak

WebSocket güçlüdür ama her chat için gerekli değildir. SSE daha basit olabilir. Connection state operasyon yükü yaratır. Proxy configuration zorlaşır. Protokol ihtiyaçtan seçilmelidir.

Streaming'i Normal JSON Gibi Parse Etmek

Streaming body tek JSON değildir. Partial chunk parse hatası verir. Event parser kullanılmalıdır. UTF-8 boundary dikkate alınmalıdır. Structured output finalde doğrulanmalıdır.

Proxy Buffering'i Unutmak

Backend tokenı hızlı gönderir. Proxy biriktirir. Kullanıcı tüm cevabı geç görür. TTFT server tarafında iyi görünür. End-to-end ölçüm problemi ortaya çıkarır.

Client Disconnect Sonrası LLM'i Çalıştırmaya Devam Etmek

Kullanıcı artık response’u görmez. Provider token üretmeye devam eder. Maliyet boşa gider. GPU kapasitesi gereksiz tüketilir. Cancellation propagate edilmelidir.

Katmanlarda Farklı Timeout Değerleri Kullanmak

CDN önce connection’ı kesebilir. Backend hala çalışmaya devam eder. Client anlamsız network error görür. Timeout budget birlikte tasarlanmalıdır. Configuration dokümante edilmelidir.

Reconnect Sonrası Duplicate Request Oluşturmak

Network koptuğunda client yeniden POST yapabilir. Eski generation çalışıyor olabilir. İki stream ve iki billing oluşur. Idempotency key gerekir. Resume state tasarlanmalıdır.

Yalnızca Ortalama Latency Ölçmek

Ortalama iyi görünse bile birçok kullanıcı yavaş olabilir. P95 ve P99 takip edilmelidir. Mobile kullanıcı ayrı segmentlenmelidir. TTFT ve total latency ayrılmalıdır. Tail problem production deneyimini belirler.

Connection Sayısını Capacity Plan'e Dahil Etmemek

RPS düşük olabilir. Ancak uzun stream binlerce connection yaratır. File descriptor ve memory tükenebilir. Active connection metric gerekir. Load test gerçek stream süresi kullanmalıdır.

Production'dan Önce Yavaş Ağ Testi Yapmamak

Local hızlı network sorunları gizler. Mobile client backpressure yaşamaz. Reconnect bug ortaya çıkmaz. Slow network testleri zorunlu olmalıdır. Partial stream failure de test edilmelidir.

Sık Sorulan Sorular

AI uygulamalarında client-server mimarisi nasıl çalışır?

Client kullanıcı girdisini backend’e gönderir. Backend authentication ve business policy uygular. Gerekirse RAG ve veritabanı işlemleri yapılır. LLM provider’a upstream request gönderilir. Yanıt REST veya streaming protokolü üzerinden client’a aktarılır.

AI uygulamasında frontend doğrudan OpenAI veya başka bir LLM API'sine bağlanmalı mı?

Production sistemlerinde genellikle bağlanmamalıdır. Provider API key frontend’de gizli tutulamaz. Kullanıcı bazlı rate limit ve cost control zorlaşır. Backend proxy güvenlik ve provider abstraction sağlar. İstemci yalnızca kurumun kendi API endpoint’ine bağlanmalıdır.

ChatGPT benzeri uygulamalarda yanıtlar nasıl stream edilir?

Backend provider streaming API’sini açar. Gelen token veya chunk’lar SSE ya da HTTP streaming ile client’a aktarılır. Client ReadableStream veya EventSource ile event’leri işler. Metin incremental render edilir. Stop ve disconnect upstream cancellation’a bağlanmalıdır.

SSE nedir?

SSE sunucudan istemciye sürekli HTTP event akışıdır. Content type text/event-stream kullanılır. Chat token streaming için uygundur. Event ID ve reconnect desteği sunabilir. Çift yönlü sürekli iletişim sağlamaz.

SSE mi WebSocket mı kullanılmalı?

Tek yönlü LLM response streaming için SSE genellikle daha basittir. Client’ın sürekli veri göndermesi gerekiyorsa WebSocket değerlendirilebilir. Voice ve realtime control çift yönlü kanal ister. Proxy ve operasyon gereksinimleri de dikkate alınmalıdır. Gereksiz karmaşık protokol seçilmemelidir.

WebSocket hangi AI uygulamalarında gereklidir?

Voice AI ve canlı audio streaming güçlü örneklerdir. Kullanıcı generation sırasında veri gönderebilir. Realtime agent ve collaborative application da faydalanabilir. Basit text chatbot için zorunlu değildir. Full-duplex gereksinim kararın ana kriteridir.

Voice AI için WebSocket mı WebRTC mi kullanılmalı?

İki teknoloji de kullanılabilir. WebSocket implementation açısından daha genel ve basittir. WebRTC gerçek zamanlı media transport için daha optimize edilmiştir. Çok düşük audio latency ve network adaptation önemliyse WebRTC değerlendirilebilir. Karar gerçek cihaz ve ağ testleriyle verilmelidir.

REST API AI chatbot için yeterli midir?

Kısa yanıtlar için yeterli olabilir. Uzun LLM yanıtlarında kullanıcı tüm response’u beklemek zorunda kalır. Streaming daha iyi UX sağlayabilir. REST yine request başlatmak ve control endpoint’leri için kullanılabilir. Protokoller birlikte kullanılabilir.

Streaming response neden localhost'ta çalışıp production'da çalışmaz?

Production’da ek proxy ve CDN katmanları bulunur. Response buffering tokenları biriktirebilir. Load balancer timeout stream’i kesebilir. WebSocket upgrade veya CORS configuration hatalı olabilir. Uçtan uca network chain debug edilmelidir.

Nginx LLM streaming'i neden geciktirir?

Nginx response buffering yapıyor olabilir. Küçük token chunk’ları memory’de birikir. Compression da flush davranışını etkileyebilir. Streaming route için buffering kapatılabilir. TTFT ve chunk timing üzerinden doğrulama yapılmalıdır.

Time to First Token nedir?

TTFT kullanıcının request göndermesi ile ilk model tokenını alması arasındaki süredir. Network, retrieval ve model queue bu değeri etkiler. Streaming kullanıcı deneyiminin önemli metriğidir. P95 TTFT production’da izlenmelidir. Model değişikliklerinde regression gösterebilir.

Backpressure nedir?

Backpressure producer ve consumer hız farkını yönetir. LLM hızlı token üretirken client yavaş okuyabilir. Sınırsız buffer memory tüketir. Flow control üretim veya aktarım hızını dengeler. Slow client testleriyle doğrulanmalıdır.

Kullanıcı bağlantıyı kapatırsa LLM isteği nasıl iptal edilir?

Server client disconnect event’i algılamalıdır. Request context cancel edilir. Upstream provider HTTP isteği kapatılır. Tool veya TTS işlemleri de sonlandırılır. Böylece gereksiz token maliyeti azaltılır.

SSE bağlantısı koparsa nasıl devam edilir?

Event ID ve stream state kullanılabilir. Client son aldığı cursor bilgisini gönderir. Server event history varsa kaldığı yerden devam eder. Resume desteklenmiyorsa eski generation iptal edilip retry yapılabilir. Duplicate generation idempotency ile engellenmelidir.

Streaming sırasında hata oluşursa ne yapılmalıdır?

Stream başladıktan sonra HTTP status değiştirilemez. Error typed event ile gönderilebilir. Client partial response’u koruyabilir. Retryable hata kullanıcıya tekrar deneme seçeneği sunabilir. Provider ve tool error ayrı kodlanmalıdır.

AI API timeout değeri nasıl seçilir?

Tek sayı tüm katmanlar için doğru değildir. Connection, idle ve total request timeout ayrı belirlenmelidir. Modelin P95 TTFT ve generation süresi ölçülmelidir. Gateway ve CDN limitleri buna uyumlu olmalıdır. Sonsuz timeout kullanılmamalıdır.

HTTP/2 LLM streaming için avantajlı mıdır?

HTTP/2 aynı connection üzerinde multiplexing sağlar. Internal service iletişiminde verim sağlayabilir. Tek SSE stream açısından fark kullanım modeline bağlıdır. TCP packet loss tüm connection’ı etkileyebilir. Gerçek performans test edilmelidir.

AI uygulamalarında API Gateway gerekli midir?

Küçük projede zorunlu olmayabilir. Kurumsal yapıda authentication, rate limit ve routing için önemli değer sağlar. Multi-provider kullanımını merkezileştirir. Cost ve audit metriklerini toplar. Gateway kendisi tek hata noktası olmayacak şekilde çalıştırılmalıdır.

Çok sayıda eşzamanlı AI stream'i nasıl ölçeklendirilir?

Stateless backend instance sayısı artırılabilir. Load balancer least-connections yaklaşımı kullanabilir. Active connection metric autoscaling’e girdi olabilir. File descriptor ve memory limitleri planlanmalıdır. Slow client ve graceful shutdown testleri yapılmalıdır.

Mobil uygulamalarda AI streaming nasıl güvenilir hale getirilir?

Connection drop normal kabul edilmelidir. Reconnection ve partial response state tasarlanmalıdır. Idempotency duplicate generation’ı engeller. Network transition test edilmelidir. Offline request queue kullanımı ürün ihtiyacına göre eklenebilir.

MCP bir client-server protokolü müdür?

MCP client ve server rollerini tanımlayan AI odaklı bir etkileşim protokolüdür. Tool ve resource discovery için ortak semantics sağlar. JSON-RPC tabanlı mesajlaşma kullanabilir. Farklı transport katmanlarında çalışabilir. Authentication ve authorization yine ayrı güvenlik tasarımı gerektirir.

AI Client-Server Ağ İletişimi Hakkında Ek Sorular

AI çözümlerinde istemci-sunucu (Client-Server) ağ iletişimi nasıl yapılandırılır?

AI client-server iletişimi frontend’in yalnızca kurumun backend endpoint’ine bağlandığı güvenli bir yapı üzerinden kurulmalıdır. Backend authentication, rate limit, request normalization ve provider bağlantısını yönetmelidir. Uzun LLM yanıtlarında SSE veya uygun streaming protokolü kullanılabilir. Client disconnect ve timeout sinyalleri model provider’a kadar propagate edilmelidir. AI Çözümlerinde İstemci-Sunucu (Client-Server) Ağ İletişimi tasarlanırken protocol seçimi kadar observability ve maliyet takibi de production gereksinimi olarak ele alınmalıdır.

Yapay zeka uygulamalarında REST API, WebSocket ve gRPC protokollerinden hangisi tercih edilmelidir?

Tek seferlik classification, embedding veya kısa LLM yanıtlarında REST çoğu zaman yeterlidir. Chat tabanlı tek yönlü token streaming için SSE veya HTTP streaming daha sade çözüm sunabilir. Realtime çift yönlü voice ve agent iletişiminde WebSocket güçlü bir seçenektir. Internal servisler arasında düşük overhead ve typed contract isteniyorsa gRPC değerlendirilebilir. Protokol teknoloji popülerliğine göre değil veri yönü, latency ve operasyon ihtiyacına göre seçilmelidir.

AI istemci-sunucu iletişiminde gecikme, timeout ve bağlantı kesintileri nasıl yönetilir?

Önce latency DNS, connection, TLS, retrieval ve model TTFT bileşenlerine ayrılmalıdır. Timeout değerleri client, gateway, proxy, backend ve provider arasında uyumlu hale getirilmelidir. Client disconnect olduğunda upstream LLM request hemen iptal edilmelidir. Reconnection sırasında idempotency ve event cursor kullanılarak duplicate generation önlenebilir. Yavaş ağ ve partial stream failure senaryoları production öncesinde load ve failure testlerine dahil edilmelidir.

Yapay zeka servislerinde istemci-sunucu veri aktarımının güvenliği ve yetkilendirmesi nasıl sağlanır?

Tüm trafik TLS üzerinden taşınmalı ve provider anahtarları yalnızca backend’de saklanmalıdır. OAuth, JWT veya güvenli session mekanizmasıyla kullanıcı identity doğrulanmalıdır. Authorization user ve tenant bazında server tarafında uygulanmalıdır. Prompt ve response logları kişisel veya kurumsal veri içerebileceği için redaction ve retention politikası gerektirir. AI veri hazırlama ve güvenli veri işleme yaklaşımıyla ilgili olarak https://www.diyarbakiryazilim.com.tr/posts/dogal-dil-isleme-nlp-modelleri-icin-ozel-veri-seti-hazirlama adresindeki içeriği de inceleyebilirsiniz.

AI istemci-sunucu mimarisi ve ağ iletişimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Yapay zeka sistem mimarisi ve API danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca model entegrasyonu sunan hizmetleri değil, network ve production operasyonunu birlikte ele alan ekipleri değerlendirmek gerekir. Danışmanlık kapsamının REST, SSE, WebSocket, timeout, security, observability ve load testing başlıklarını içermesi önemlidir. Yapılan projeleri görmek için https://www.diyarbakiryazilim.com.tr/projects adresini inceleyebilirsiniz. Diyarbakır Yazılım Topluluğu hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresinden topluluk yaklaşımına ulaşabilirsiniz. Kurumsal AI client-server mimarisi ve API entegrasyon hizmeti planlanırken ilk aşamada mevcut network akışının ölçülmesi genellikle en verimli başlangıç noktasıdır.

Sonuç: Güvenilir AI Client-Server İletişimi Nasıl Tasarlanır?

AI Çözümlerinde İstemci-Sunucu (Client-Server) Ağ İletişimi yalnızca frontend’in bir LLM API’ye HTTP isteği göndermesi olarak görülmemelidir. Production ortamında protocol seçimi, streaming, cancellation, timeout, idempotency, rate limiting ve observability birlikte çalışan bir dağıtık sistem problemi oluşturur. Basit chat için SSE yeterli olabilirken voice ve realtime agent sistemleri WebSocket veya WebRTC gerektirebilir. API key ve model provider detaylarının backend’de tutulması güvenlik ve vendor bağımsızlığı açısından güçlü bir temel sağlar. Mimari, performans, streaming veya API entegrasyonu konusunda destek almak için https://www.diyarbakiryazilim.com.tr adresi üzerinden Diyarbakır Yazılım Topluluğu ile iletişime geçebilirsiniz.

Protokolü Kullanım Senaryosuna Göre Seçin

Her AI uygulaması WebSocket gerektirmez. REST kısa request-response için güçlüdür. SSE tek yönlü LLM stream’de pratiktir. WebSocket çift yönlü etkileşimde avantaj sağlar. WebRTC gerçek zamanlı media için değerlendirilmelidir.

Provider Kimlik Bilgilerini Backend'de Tutun

Frontend içinde secret saklanamaz. Provider key backend secret store’da bulunmalıdır. Rotation otomatik yapılabilir. User authorization ayrı uygulanmalıdır. Sızan client kodu provider hesabını açığa çıkarmamalıdır.

Metin Tabanlı LLM Streaming'de SSE'yi Varsayılan Olarak Değerlendirin

Chat yanıtı çoğu zaman tek yönlü akar. SSE mevcut HTTP altyapısıyla iyi çalışır. Typed event protocol uygulanabilir. Proxy buffering kapatılmalıdır. Gerçek çift yönlü ihtiyaç yoksa daha basit çözüm tercih edilebilir.

Gerçek Çift Yönlü Trafikte WebSocket veya WebRTC Kullanın

Voice AI sürekli input ve output üretir. WebSocket general-purpose full-duplex kanal sağlar. WebRTC media latency için daha optimize olabilir. Realtime agent control event’leri çift yönlüdür. Operasyon maliyeti kullanım faydasıyla dengelenmelidir.

Streaming'i Uçtan Uca Bir Zincir Olarak Tasarlayın

Backend’in stream yazması tek başına yeterli değildir. Reverse proxy buffer etmemelidir. CDN timeout stream’i kesmemelidir. Client incremental parse yapmalıdır. TTFT uçtan uca ölçülmelidir.

Client Disconnect'i Upstream'e Kadar Propagate Edin

Kullanıcı response’u artık görmüyorsa model çalışmaya devam etmemelidir. Client abort server tarafından algılanmalıdır. Provider request iptal edilmelidir. Tool ve TTS task’ları durmalıdır. Gereksiz token ve GPU maliyeti azaltılmalıdır.

Timeout, Retry ve Idempotency'yi Birlikte Tasarlayın

Timeout sonrası retry duplicate generation oluşturabilir. Idempotency key aynı logical işlemi korur. Retry yalnızca geçici hatalarda yapılmalıdır. Backoff ve jitter uygulanmalıdır. Streaming başladıktan sonraki retry ayrı politika gerektirir.

Connection Sayısını Ölçeklendirme Hesabına Dahil Edin

RPS uzun stream sistemini açıklamaz. Concurrent connection gerçek kaynak tüketimini gösterir. File descriptor ve memory limitleri ölçülmelidir. Slow client load test yapılmalıdır. Connection headroom node failure durumunu karşılamalıdır.

TTFT ve Stream Completion Rate'i Sürekli İzleyin

TTFT kullanıcıya ilk cevabın hızını gösterir. Completion rate bağlantı güvenilirliğini ölçer. P95 değerleri ortalamadan daha anlamlıdır. Provider ve region bazında segmentasyon yapılabilir. Regression release sürecinde otomatik alarm oluşturabilir.

AI Ağ İletişimini Yalnızca API Çağrısı Değil Production Dağıtık Sistem Problemi Olarak Ele Alın

AI uygulaması DNS, TLS, proxy, gateway, model ve client katmanlarının birlikte çalıştığı bir sistemdir. Her katman latency veya failure üretebilir. Security ve cost kontrolü yalnızca model provider’a bırakılamaz. Failure testing ve observability production hazırlığının temelidir. Bu bakış açısı AI entegrasyonlarının daha güvenilir, ölçülebilir ve sürdürülebilir çalışmasını sağlar.