AI Uygulamalarında Ön Uç ve Arka Uç Arasında Durum Yönetimi

AI ile oluşturulan bir uygulamada “durum” ne demektir

“Durum”, uygulamanızın bir andan diğerine doğru davranması için hatırlaması gereken her şeydir.

Bir kullanıcı sohbet arayüzünde Göndere tıkladığında, uygulama kullanıcının yazdıklarını, asistanın zaten ne cevapladığını, bir isteğin hâlâ çalışıp çalışmadığını veya hangi ayarların (ton, model, araçlar) etkin olduğunu unutmamalıdır. Bunların hepsi durumdur.

Basitçe durum

Durumu düşünmenin kullanışlı bir yolu: uygulamanın o anki gerçeği—kullanıcının gördüklerini ve sistemin bir sonraki adımda ne yapacağını etkileyen değerler. Bu, form girdileri gibi bariz şeyleri içerir, ama ayrıca “görünmez” gerçekler de vardır:

• Kullanıcının hangi konuşmada olduğu
• Son cevabın akış halinde mi yoksa tamamlanmış mı olduğu
• Mesaj listesi ve sıralaması
• Araç çağrıları ve araç sonuçları (arama sonuçları, veritabanı sorguları, dosya özetleri)
• Hatalar, yeniden denemeler ve hız sınırlama geri çekilmesi

Neden AI uygulamalarında daha çok hareketli parça var

Geleneksel uygulamalar genellikle veriyi okur, gösterir ve güncellemeleri kaydeder. AI uygulamaları ekstra adımlar ve ara çıktılar ekler:

• Tek bir kullanıcı eylemi birden çok arka uç işlemi tetikleyebilir (LLM çağrısı, araç çağrısı, başka bir LLM çağrısı).
• Yanıtlar kademeli (akış halinde token'lar) gelebilir, bu yüzden UI kısmi durumu yönetmek zorunda kalır.
• Bağlam önemlidir: sistem, konuşma belleğini, araç çıktıları ve model ayarlarını istekler arasında tutarlı hale getirmelidir.

Bu ekstra hareket, durum yönetiminin AI uygulamalarında genellikle gizli karmaşıklık olmasının nedenidir.

Bu kılavuz neleri kapsayacak

İlerleyen bölümlerde durumu pratik kategorilere ayıracağız (UI durumu, oturum durumu, kalıcı veri ve model/çalışma zamanı durumu) ve her birinin nerede durması gerektiğini (ön uç vs. arka uç) göstereceğiz. Ayrıca eşitleme, önbellekleme, uzun süren işler, akışlı güncellemeler ve güvenlik konularını ele alacağız—çünkü durum yalnızca doğruysa faydalıdır ve korunmalıdır.

Hızlı örnek senaryo

Kullanıcının “Geçen ayın faturalarını özetle ve olağan dışı bir şey varsa işaretle.” dediğini hayal edin. Arka uç muhtemelen (1) faturaları getirir, (2) bir analiz aracı çalıştırır, (3) özetini UI'ya akışla gönderir ve (4) nihai raporu kaydeder.

Bunun sorunsuz hissettirmesi için uygulama mesajları, araç sonuçlarını, ilerlemeyi ve kaydedilen çıktıyı takip etmelidir—konuşmaları karıştırmadan veya kullanıcılar arasında veri sızdırmadan.

Durumun dört katmanı: UI, oturum, veri ve model

AI uygulamalarında insanlar “durum” derken genellikle çok farklı şeyleri karıştırırlar. Durumu dört katmana ayırmak—UI, oturum, veri ve model/çalışma zamanı—bir şeyin nerede yaşamaması gerektiğine, kimin değiştirebileceğine ve nasıl saklanacağına karar vermeyi kolaylaştırır.

1) UI durumu (kullanıcının şu an ne yaptığı)

UI durumu tarayıcıda veya mobil uygulamada canlı, anlık durumlardır: metin girdileri, açık/kapalı anahtarlar, seçili öğeler, hangi sekmenin açık olduğu ve bir butonun devre dışı olup olmadığı gibi.

AI uygulamaları birkaç UI-özel ayrıntı ekler:

• Yükleniyor göstergeleri ve “düşünüyor” durumları
• Akış halinde gelen token'lar (üretildikçe görünen kısmi metin)
• Gönderilmeden önceki yerel taslak mesajlar

UI durumu kolayca sıfırlanabilir ve kaybolması genellikle güvenlidir. Kullanıcı sayfayı yenilerse bu durum kaybolabilir—ve çoğu durumda bu kabul edilebilir.

2) Oturum / konuşma durumu (kullanıcının akışı için paylaşılan bağlam)

Oturum durumu bir kullanıcıyı devam eden bir etkileşime bağlar: kullanıcı kimliği, bir konuşma kimliği ve mesaj geçmişinin tutarlı bir görünümü.

AI uygulamalarında bu genellikle şunları içerir:

• Mesaj geçmişi (veya ona referanslar)
• Araç izleri (hangi fonksiyon/araç çağrıldı ve hangi sonuçlar döndü)
• Geçerli proje/doküman, seçili model veya çalışma alanı gibi “çalışma seti” seçimleri

Bu katman genellikle ön uç ve arka uç arasında paylaşılır: ön uç hafif kimlik bilgilerini tutar, arka uç ise oturum sürekliliği ve erişim kontrolü için yetkilidir.

3) Veri durumu (depolamada kalıcı kayıtlar)

Veri durumu veritabanında kasıtlı olarak sakladıklarınız: projeler, dokümanlar, embedding'ler, tercihler, denetim günlükleri, faturalama olayları ve kaydedilmiş konuşma transkriptleri.

UI ve oturum durumunun aksine, veri durumu şunlar olmalıdır:

• Kalıcı (yeniden başlatmalarda korunur)
• Sorgulanabilir (arama/filtreleme yapılabilir)
• Denetlenebilir (sonradan ne olduğunu anlayabilirsiniz)

4) Model / çalışma zamanı durumu (AI'nın şu an nasıl yapılandırıldığı)

Model/çalışma zamanı durumu bir cevabı üretmek için kullanılan operasyonel ayardır: sistem prompt'ları, etkin araçlar, temperature/max token, güvenlik ayarları, hız sınırları ve geçici önbellekler.

Bunların bir kısmı konfigürasyondur (kararlı varsayılanlar); bir kısmı ise geçicidir (kısa ömürlü önbellekler veya istek başına token bütçeleri). Çoğu arka uçtadır ki tutarlı şekilde kontrol edilebilsin ve gereksiz yere açığa çıkmasın.

Ayrım hataları neden hataları azaltır

Bu katmanlar bulanıklaştığında klasik hatalar ortaya çıkar: UI kaydedilmemiş metin gösterir, arka uç ön uçun beklediği prompt ayarlarını kullanmaz veya konuşma belleği kullanıcılar arasında sızar. Net sınırlar daha açık gerçek kaynakları oluşturur—neyin kalıcı olması gerektiğini, neyin yeniden hesaplanabileceğini ve neyin korunması gerektiğini belirginleştirir.

Ön uçta vs. arka uçta ne yaşar (ve neden)

AI uygulamalarında hataları azaltmanın güvenilir bir yolu her durum parçası için nerede olması gerektiğine karar vermektir: tarayıcıda (ön uç), sunucuda (arka uç) veya her ikisinde. Bu seçim güvenilirliği, güvenliği ve kullanıcıların sayfa yenileme, yeni sekme açma veya ağ bağlantısı kaybetme durumlarında uygulamanın ne kadar sürprizli olacağına etki eder.

Ön uç durumu: hızlı, geçici ve kullanıcı odaklı

Ön uç durumu hızlı değişen ve yenileme sırasında hayatta kalması gerekmeyen şeyler için en iyisidir. Bunu yerelde tutmak UI'yı duyarlı yapar ve gereksiz API çağrılarını önler.

Ortak ön uç-ağırlıklı örnekler:

• Kullanıcının yazdığı taslak mesaj metni
• Bir tablodaki yerel filtreler ve sıralama
• Modal açık/kapalı durumu, seçili sekme, hover durumları

Bu durum yenilendiğinde kayboluyorsa genellikle kabul edilebilir.

Arka uç durumu: yetkili, hassas ve paylaşılan

Arka uç durumu, güvenilir olması, denetlenmesi veya tutarlı bir şekilde uygulanması gereken her şeyi tutmalıdır. Bu, diğer cihazlar/sekmelerin görmesi gereken veya istemci değiştirildiğinde doğru kalması gereken durumları içerir.

Ortak arka uç-ağırlıklı örnekler:

• İzinler ve roller (kullanıcının ne yapabileceği)
• Fatura/abonelik durumu ve kullanım sınırları
• Uzun süren işler (doküman indeksleme, büyük dışa aktarmalar, fine-tune çalışmaları) ve bunların durumu

İyi bir zihniyet: yanlış durum para kaybettiriyorsa, veri sızdırıyorsa veya erişim kontrolünü bozuyorsa, arka uçta olmalıdır.

Paylaşılan durum: koordine edilir, ama bir gerçek kaynağı olur

Bazı durumlar doğası gereği paylaşımdır:

• Konuşma başlığı
• Bir sohbet için seçili bilgi kaynakları
• Cihazlar arası kullanılan kullanıcı profil alanları

Paylaşılsa bile, bir “gerçek kaynak” seçin. Genellikle arka uç yetkilidir ve ön uç hız için bir kopya önbellekler.

Kural-of-thumb (ve yaygın bir antipattern)

Durumu gerektiği yere yakın tutun, ama yenileme, cihaz değişikliği veya kesintiler sonrası kalması gerekenleri kalıcılaştırın.

Sadece tarayıcıda yetkili veya hassas durum saklamak gibi antipattern'lerden kaçının (ör. istemci tarafı isAdmin bayrağını gerçek kabul etmek). UI bu değerleri gösterebilir, ama arka uç bunları doğrulamalıdır.

Tipik bir AI istek yaşam döngüsü: tıklamadan tamamlanmaya

Bir AI özelliği “tek eylem” gibi görünse de gerçekte tarayıcı ile sunucu arasında paylaşılan durum geçişleri zinciridir. Yaşam döngüsünü anlamak, uyumsuz UI, eksik bağlam ve yinelenen ücretlendirmelerden kaçınmayı kolaylaştırır.

1) Kullanıcı eylemi → ön uç niyeti hazırlar

Kullanıcı Göndere tıklar. UI hemen yerel durumu günceller: bir “beklemede” mesaj balonu ekleyebilir, gönder butonunu devre dışı bırakabilir ve mevcut girdileri (metin, ekler, seçili araçlar) yakalayabilir.

Bu noktada ön uç korelasyon kimlikleri üretmeli veya eklemelidir:

• conversation_id: hangi konuya ait olduğu
• message_id: yeni kullanıcı mesajı için istemci tarafından atanan kimlik
• request_id: deneme başına benzersiz (yeniden denemeler için faydalı)

Bu ID'ler, yanıtlar geç veya çift gelse bile her iki tarafın aynı olaydan bahsetmesini sağlar.

2) API çağrısı → sunucu doğrular ve kalıcı hale getirir

Ön uç, kullanıcı mesajı ve ID'lerle birlikte bir API isteği gönderir. Sunucu izinleri, hız sınırlarını ve payload yapısını doğrular; sonra kullanıcı mesajını (veya en azından değiştirilemez bir günlük kaydını) conversation_id ve message_id ile anahtarlayarak persist eder.

Bu kalıcılık adımı, kullanıcı isteği sırasında sayfayı yenilediğinde “hayalet geçmiş” olmasını engeller.

3) Sunucu bağlamı yeniden oluşturur

Modeli çağırmak için sunucu gerçek kaynaklarından bağlamı yeniden inşa eder:

• conversation_id için son mesajları getir
• İlgili kayıtları (dokümanlar, tercihler, araç çıktıları) çek
• Konuşma politikalarını uygula (sistem prompt'ları, bellek kuralları, kırpma)

Ana fikir: tam geçmişi istemciden almaya güvenmeyin. İstemci eski olabilir.

4) Model/araç yürütmesi → ara durum

Sunucu, model çağrısından önce veya sırasında araç çağrıları (arama, veritabanı sorgusu) yapabilir. Her araç çağrısı request_id ile izlenmeli ki denetlenebilsin ve güvenle yeniden çalıştırılabilsin.

5) Yanıt (akışlı veya değil) → UI tamamlanması

Akışlı çalışmada, sunucu kısmi token/olay gönderir. UI beklemedeki asistan mesajını kademeli olarak günceller, ancak nihai olay gelene kadar mesajı “devam ediyor” olarak değerlendirir.

6) Planlanması gereken hata noktaları

Yeniden denemeler, çift gönderimler ve sıra dışı yanıtlar olabilir. Sunucuda deduplama için request_id kullanın ve UI'da uzaktaki parçaları aktife uymuyorsa yok saymak için message_id kullanın. Her zaman yinelenmeyen güvenli bir yeniden deneme ile net bir “başarısız” durumu gösterin.

Oturumlar ve konuşma belleği: bağlamı kaosa dönüştürmeden tutmak

Oturum, bir kullanıcının eylemlerini bağlayan “ileti dizisidir”: hangi çalışma alanında oldukları, son aradıkları, hangi taslağı düzenledikleri ve hangi konuşmanın bir AI cevabını devam ettireceği. İyi oturum durumu sayfalar arasında uygulamayı sürekli hissettirir—ve ideal olarak cihazlar arasında da—ama arka ucu kullanıcının söylediklerinin her şeyini saklayan bir çöplüğe çevirmeden.

Oturum durumu hedefleri

Hedefleyin: (1) süreklilik (kullanıcı ayrılıp geri dönebilir), (2) doğruluk (AI doğru konuşma için doğru bağlamı kullanır) ve (3) kapsama (bir oturum diğerine sızmaz). Birden çok cihazı destekliyorsanız, oturumları kullanıcı-ölçekli artı cihaz-ölçekli olarak ele alın: “aynı hesap” her zaman “aynı açık çalışma” anlamına gelmez.

Çerezler vs. tokenlar vs. sunucu oturumları

Genellikle bu yollardan birini seçersiniz:

• Çerezler: web uygulamaları için en basiti; tarayıcı bunları otomatik gönderir. Geleneksel oturumlar için iyidir, ancak güvenli bayrakları (HttpOnly, Secure, SameSite) ayarlamalı ve CSRF ile düzgün uğraşmalısınız.
• Tokenlar (ör. JWT): mobil ve API'ler için iyi çünkü istemci bunları açıkça ekleyebilir. İyi ölçeklenir, ama iptal ve döndürme ekstra tasarım gerektirir (ve hassas durumu token içinde depolamamalısınız).
• Sunucu oturumları: sunucu oturum verilerini (genellikle Redis gibi) saklar, istemci sadece opak bir oturum ID'si taşır. İptal ve güncelleme en kolay olanıdır, ama oturum deposunu işletip ölçeklendirmeniz gerekir.

Konuşma bellek stratejileri

“Bellek”, modele geri göndermeyi seçtiğiniz durumdur.

• Tam geçmiş: en doğru, ama maliyetli ve eski hassas içeriği ortaya çıkarabilir.
• Özetlenmiş geçmiş: sürekli bir özet artı birkaç son tur; daha ucuz ve genellikle “yeterince iyi”.
• Pencere tabanlı bağlam: sadece son N mesaj; en basit, ama önemli önceki kararları kaybedebilir.

Pratik bir desen özet + pencere'dir: öngörülebilir ve modeli şaşırtıcı davranışlardan korur.

Araç çağrıları: tekrar edilebilir ve denetlenebilir

AI araçları kullanıyorsa (arama, veritabanı sorguları, dosya okumalar), her araç çağrısını girdiler, zaman damgaları, araç sürümü ve dönen çıktıyla birlikte saklayın (veya ona referans). Bu, “neden böyle dediğini” açıklamanıza, debug için çalıştırmaları yeniden oynamanıza ve bir araç veya veri seti değiştiğinde sonuçların neden değiştiğini tespit etmenize izin verir.

Gizlilik güvenlikleri

Varsayılan olarak uzun süreli bellek saklamayın. Süreklilik için yalnızca gerektiğini saklayın (konuşma kimlikleri, özetler ve araç günlükleri), saklama süreleri belirleyin ve ham kullanıcı metnini yalnızca açık bir ürün nedeni ve kullanıcı onayı varsa saklayın.

Durumu güvenli şekilde eşitleme: gerçek kaynaklar ve çakışma yönetimi

Aynı “şey” birden çok yerden düzenlenebiliyorsa—UI, ikinci bir tarayıcı sekmesi veya konuşmayı güncelleyen bir arka plan işi—durum risklidir. Çözüm zekice koddan çok net sahipliktir.

Gerçek kaynakları tanımlayın

Her durum parçası için hangi sistemin yetkili olduğunu belirleyin. Çoğu AI uygulamasında, kanonik kayıt için arka uç sahiplenmelidir: konuşma ayarları, araç izinleri, mesaj geçmişi, faturalama sınırları ve iş durumu. Ön uç hız için önbellek ve türetme yapabilir (seçili sekme, taslak prompt metni, “yazıyor” göstergeleri), ama uyumsuzlukta arka ucunun doğru olduğunu varsaymalıdır.

Pratik kural: yenilemede kaybetmek sizi üzecekse, muhtemelen arka uçtadır.

İyimser UI güncellemeleri (dikkatle kullanın)

İyimser güncellemeler uygulamayı anlık hissettirir: bir ayarı değiştirin, UI'ı hemen güncelleyin, sonra sunucuyla onaylayın. Bu düşük riskli, geri alınabilir eylemler (örn. bir konuşmayı yıldızlamak) için iyi çalışır.

Sunucu reddedebileceği veya değiştirip dönüştürebileceği durumlarda (izin kontrolleri, kota, doğrulama veya sunucu tarafı varsayılanları) kafa karışıklığı yaratır. Bu durumlarda “kaydediliyor…” görünüp UI'ı yalnızca onaydan sonra güncelleyin.

Çakışmalarla başa çıkma (iki sekme, bir konuşma)

İki istemci aynı kaydı farklı başlangıç versiyonlarına dayanarak güncellediğinde çakışmalar olur. Örnek: Sekme A ve Sekme B aynı anda model temperature'ını değiştiriyor.

Sunucunun eski yazıları tespit etmesi için hafif sürümlendirme kullanın:

• updated_at zaman damgaları (basit, insan tarafından anlaşılabilir)
• ETag / If-Match başlıkları (HTTP tabanlı)
• Artan revizyon numaraları (açık çakışma algılama)

Versiyon uymuyorsa, bir çakışma yanıtı (genellikle HTTP 409) döndürün ve en son sunucu nesnesini gönderin.

API'leri uyumsuzluğu azaltacak şekilde tasarlayın

Her yazma işleminden sonra API saklanan nesneyi olduğu gibi döndürsün (sunucu tarafından üretilen varsayılanlar, normalleştirilmiş alanlar ve yeni versiyon dahil). Bu, ön ucun önbelleğini doğru şekilde değiştirmesine izin verir—neyin değiştiğini tahmin etmek yerine tek bir gerçek-kaynak güncellemesi sağlar.

Önbellekleme ve performans: hızlı ama güncel olmayan olmadan hızlandırma

Önbellekleme, AI uygulamasını anında hissettirmenin en hızlı yollarından biridir, ancak aynı zamanda durumu ikinci bir kopyada oluşturur. Yanlış şeyi veya yanlış yerde önbelleğe alırsanız, hızlı ama kafa karıştırıcı bir UI sunarsınız.

İstemci tarafında ne önbelleğe alınır

İstemci önbellekleri deneyime odaklanmalıdır, otoriteye değil. İyi adaylar: son konuşma önizlemeleri (başlıklar, son mesaj kesiti), UI tercihleri (tema, seçili model, kenar çubuğu durumu) ve iyimser UI durumu (gönderilen ama henüz tamamlanmamış mesajlar).

İstemci önbelleğini küçük ve geçici tutun: temizlense bile uygulama sunucudan yeniden alarak çalışabilmeli.

Sunucu tarafında ne önbelleğe alınır

Sunucu önbellekleri pahalı veya sık tekrar edilen işleri hızlandırmaya odaklanmalıdır:

• Yeniden kullanılmasında güvenli olan araç sonuçları (örn. aynı şehir için hava durumu, 5 dakika içinde)
• Tekrarlanan sorgular için embedding aramaları ve vektör sonuçları (kısa TTL ile)
• API'nizi ve maliyetlerinizi korumak için hız-limiti durumu ve throttling sayaçları

Ayrıca token sayıları, moderasyon kararları veya doküman parse çıktıları gibi türetilmiş durumu önbelleğe alabilirsiniz—deterministik ve maliyetli olan her şey.

Önbellek geçersiz kılma temelleri (çok karışmadan)

Üç pratik kural:

1. Girdi(leri) (user_id, model, araç parametreleri, doküman versiyonu) kodlayan net önbellek anahtarları kullanın.
2. Temel verinin ne kadar hızlı değiştiğine göre TTL'ler belirleyin. Kısa TTL, karmaşık mantıktan iyidir.
3. Doğruluk hızdan daha önemliyse önbelleği atlayın: bir kullanıcı bir dokümanı güncelledikten, izinleri değiştirdikten veya yenileme istediğinde.

Bir önbellek kaydı ne zaman yanlış olur açıklayamıyorsanız, onu önbelleğe almayın.

Gizli veya kişisel verileri paylaşılan önbelleklere koymayın

API anahtarları, kimlik belirteçleri, hassas metin içeren ham prompt'lar veya kullanıcıya özel içeriği CDN gibi paylaşılan katmanlara koymaktan kaçının. Kullanıcı verilerini önbelleğe almanız gerekiyorsa, kullanıcı bazında izole edin ve disk üzerinde şifreleyin—ya da bunları birincil veritabanında saklayın.

Etkiyi ölçün: hız vs. güncellenmemiş UI

Önbellekleme varsayılan değil, kanıtlanmış olmalı. p95 gecikmeyi, önbellek vuruş oranını ve kullanıcı tarafından görülen hataları (ör. “mesaj render'dan sonra güncellendi”) takip edin. Daha sonra UI ile çelişen hızlı bir yanıt, biraz daha yavaş ama tutarlı olandan sıklıkla daha kötüdür.

Kalıcılık ve uzun süren işler: işler, kuyruklar ve durum durumu

Bazı AI özellikleri saniyeler içinde biter. Diğerleri dakika alır: bir PDF yükleme ve parse etme, bilginin embedding'lenip indekslenmesi veya çok adımlı bir araç iş akışı. Bu tür işler için “durum” sadece ekrandakiler değil—yenilemeleri, yeniden denemeleri ve zaman içinde ayakta kalan şeylerdir.

Neyi kalıcı hale getirmeli (ve neden)

Gerçek ürün değeri sağlayanı kalıcılaştırın.

Konuşma geçmişi bariz olan: mesajlar, zaman damgaları, kullanıcı kimliği ve genellikle hangi model/araç kullanıldığı. Bu “sonra devam et” imkanı, denetim izi ve daha iyi destek için gereklidir.

Kullanıcı ve çalışma alanı ayarları veritabanında olmalı: tercih edilen model, temperature varsayılanları, özellik açma/kapama, sistem prompt'ları ve cihazlar arasında geçmesi gereken UI tercihleri.

Dosyalar ve artefaktlar (yüklemeler, çıkarılmış metin, üretilen raporlar) genellikle obje depolamada tutulur ve veritabanı bunlara işaret eden kayıtlar tutar. Veritabanı metadata'yı (sahip, boyut, içerik türü, işlenme durumu) tutar, blob store ise baytları tutar.

Uzun işler için arka plan işleri

Bir istek normal HTTP zaman aşımında güvenilir şekilde tamamlanamayacaksa işi kuyruğa taşıyın.

Tipik bir desen:

• Ön uç POST /jobs gibi bir API çağrısı yapar (dosya id, konuşma id, parametreler).
• Arka uç bir iş kuyruğuna ekler (çıkartma, indeksleme, toplu araç çalıştırma) ve hemen bir job_id döner.
• Worker'lar işleri asenkron işler ve sonuçları kalıcı depoya yazar.

Bu, UI'yı duyarlı tutar ve yeniden denemeleri daha güvenli kılar.

UI'nın güvenebileceği durum durumu

İş durumunu açık ve sorgulanabilir yapın: queued → running → succeeded/failed (opsiyonel olarak canceled). Bu geçişleri sunucu tarafında zaman damgaları ve hata detaylarıyla saklayın.

Ön uçta durumu açıkça yansıtın:

• Queued/running: spinner gösterin ve yinelenen eylemleri devre dışı bırakın.
• Failed: kısa bir hata gösterin ve bir Yeniden Dene butonu sunun.
• Succeeded: oluşan artefaktı yükleyin veya konuşmayı güncelleyin.

GET /jobs/{id} (polling) veya SSE/WebSocket ile akış sağlayın ki UI tahmin yürütmek zorunda kalmasın.

Idempotency anahtarları: yeniden denemelerde çift yazmayı önleme

Ağ zaman aşımı olur. Ön uç POST /jobsu yeniden denediğinde iki aynı iş istemezsiniz (ve iki fatura gelmez).

Her mantıksal eylem için bir Idempotency-Key zorunlu kılın. Arka uç anahtarı sonuçla beraber saklar ve tekrar eden isteklere aynı sonucu döndürür.

Temizlik ve sona erme politikaları

Uzun süreli AI uygulamaları hızla veri biriktirir. Saklama kurallarını erkenden tanımlayın:

• Eski konuşmaları N gün sonra silin (veya kullanıcıya yapılandırma imkanı verin).
• Türev artefaktları kaynak silindiğinde silin.
• Başarısız işleri ve ara dosyaları periyodik olarak temizleyin.

Temizliği durum yönetiminin bir parçası olarak ele alın: risk, maliyet ve kafa karışıklığını azaltır.

Akışlı yanıtlar ve gerçek zamanlı güncellemeler: kısmi durum yönetimi

Akışlı cevaplar “cevap” artık tek bir blob değil demektir. Kelime kelime gelen kısmi token'larla (ve bazen kısmi araç sonuçlarıyla) uğraşıyorsunuz. Bu, UI ve arka ucun geçici ile nihai durumu ne olarak sayacağı konusunda anlaşmasını gerektirir.

Arka uç: sadece metin değil, türlenmiş olaylar akıtın

Temiz bir desen, tür ve yük içeren küçük olaylar dizisi akıtmaktır. Örneğin:

• token: kademeli metin (veya küçük bir parça)
• tool_start: bir araç çağrısı başladı (ör. “Aranıyor…”, bir id ile)
• tool_result: araç çıktısı hazır (aynı id)
• done: asistan mesajı tamamlandı
• error: bir şey bozuldu (kullanıcıya güvenli bir mesaj ve debug id'si dahil)

Bu olay akışı düz metin akışından daha kolay sürümlenebilir ve debug edilebilir; çünkü ön uç ilerlemeyi doğru şekilde render edebilir (ve araç durumunu gösterebilir) tahmin etmek zorunda kalmadan.

Ön uç: eklemesine güncellemeler, sonra nihai onay

İstemcide akışı eklemeye dayalı olarak ele alın: bir “taslak” asistan mesajı oluşturun ve token olayları geldikçe genişletin. done aldığınızda commit yapın: mesajı nihai olarak işaretleyin, (yerel saklıyorsanız) kalıcı hale getirin ve kopyalama, puanlama veya yeniden üretme gibi eylemleri açın.

Bu, akış sırasında geçmişi yeniden yazmaktan kaçınır ve UI'nızı öngörülebilir kılar.

Kesintilerle başa çıkma (iptal, bağlantı kopmaları, zaman aşımı)

Akış, yarım kalmış işleri daha olası kılar:

• Kullanıcı iptal etti: iptal sinyali gönderin; token render'ını durdurun; taslağı görünür şekilde iptal edilmiş gösterin.
• Ağ kopması: akışı durdurun; “yeniden bağlanılıyor…” gösterin ve tamamlanmayı varsaymayın.
• Sunucu zaman aşımı/hataları: taslağı başarısız olarak sonuçlandırın ve yeni bir istek başlatan bir yeniden dene sunun (akışları sessizce birleştirmeyin).

Yeniden yükleme: stabil durumu yeniden oluşturma

Sayfa akış ortasında yenilenirse, en son kararlı durumdan yeniden oluşturun: son commit edilmiş mesajlar artı saklanmış taslak metadata'sı (message id, biriken metin, araç durumları). Akışı devam ettiremiyorsanız taslağı kesintili olarak gösterin ve kullanıcının yeniden denemesine izin verin; tamamlandı gibi göstermeyin.

Güvenlik ve gizlilik: uçtan uca durum koruması

Durum sadece sakladığınız veri değildir—kullanıcının prompt'ları, yüklemeleri, tercihleri, üretilen çıktılar ve bunları birbirine bağlayan metadata da durumdur. AI uygulamalarında bu durum olağanüstü derecede hassas olabilir (kişisel bilgi, tescilli dokümanlar, iç kararlar), bu yüzden güvenlik her katmana tasarlanmalı.

Gizli anahtarları sunucuda tutun

Bir istemcinin uygulamanızı taklit etmesine izin verecek her şey arka uçta kalmalıdır: API anahtarları, özel konektörler (Slack/Drive/DB kimlik bilgileri) ve dahili sistem prompt'ları veya yönlendirme mantığı. Ön uç bir eylem isteyebilir (“bu dosyayı özetle”), ama arka uç nasıl ve hangi kimliklerle çalıştırılacağına karar vermelidir.

Her yazmayı yetkilendirin (ve çoğu okumayı)

Her durum mutasyonunu ayrıcalıklı bir işlem olarak değerlendirin. İstemci bir mesaj oluşturduğunda, bir konuşmayı yeniden adlandırdığında veya bir dosya eklediğinde arka uç doğrulamalıdır:

• Kullanıcı kimliği doğrulanmış mı?
• Kullanıcı kaynağa sahip mi (konuşma, çalışma alanı, proje)?
• Kullanıcı bu eylemi yapmaya yetkili mi (rol, plan sınırları, organizasyon politikası)?

Bu, birinin conversation_id tahmin edip başka bir kullanıcının geçmişine erişmesini engeller.

Tarayıcıya asla güvenmeyin: doğrulayın ve temizleyin

İstemciden gelen her durumu güvensiz girdi olarak kabul edin. Şemayı ve kısıtları doğrulayın (tipler, uzunluklar, izin verilen enum'lar) ve hedefe göre temizleyin (SQL/NoSQL, loglar, HTML render). “Durum güncellemeleri” kabul ediyorsanız, rastgele JSON birleştirmek yerine izin verilen alanları beyaz listeye alın.

Kritik eylemler için denetim izleri

Kalıcı durumu değiştiren eylemler—paylaşma, dışa aktarma, silme, konektör erişimi—için kim ne zaman ne yaptı kaydedin. Hafif bir denetim günlüğü olay müdahalesi, müşteri desteği ve uyumluluk için yardımcı olur.

Veri minimizasyonu ve şifreleme

Sadece özelliği sunmak için gerekeni saklayın. Prompt'ları sonsuza dek tutmanız gerekmiyorsa saklama pencereleri veya kırpma düşünün. Hassas durumu disk üzerinde şifreleyin (tokenlar, konektör kimlik bilgileri, yüklenen dokümanlar) ve iletişimde TLS kullanın. Operasyonel metadata ile içeriği ayrıştırın ki içeriğe erişimi daha sıkı kısıtlayabilesiniz.

Pratik referans mimarisi ve bir inşa kontrol listesi

AI uygulamaları için kullanışlı bir varsayılan basit: arka uç gerçek kaynak olsun, ön uç hızlı, iyimser bir önbellek olsun. UI anlık hissedebilir, ama kaybolduğunda üzüleceğiniz her şey (mesajlar, iş durumu, araç çıktıları, fatura-ilişkili olaylar) sunucu tarafında onaylanmalı ve saklanmalıdır.

Eğer çok hızlı üretim yapan bir “vibe-coding” iş akışıyla inşa ediyorsanız—çok fazla ürün yüzeyi hızlıca üretiliyorsa—durum modeli daha da önemli olur. Koder.ai gibi platformlar ekiplerin chat'ten tam web, arka uç ve mobil uygulamalar göndermesine yardım edebilir, ama aynı kural geçerlidir: hızlı yineleme, gerçek kaynaklarınız, ID'leriniz ve durum geçişleriniz önden tasarlandığında en güvenlidir.

Sevk mimarisi (hızla gönderilebilir)

Ön uç (tarayıcı/mobil)

• UI durumu: açık paneller, taslak prompt metni, seçili model, geçici “yazılıyor” göstergeleri.
• Önbelleğe alınmış sunucu durumu: son konuşmalar, son bilinen iş durumu, kısmi akış tamponu.
• Her zaman ekleyen tek bir istek hattı: session_id, conversation_id ve yeni bir request_id eklenir.

Arka uç (API + worker'lar)

• API servisi: girdiyi doğrular, kayıt oluşturur, akışlı yanıtlar üretir.
• Kalıcı mağaza (SQL/NoSQL): konuşmalar, mesajlar, araç çağrıları, iş durumu.
• Kuyruk + worker'lar: uzun süren işler (RAG indeksleme, dosya parse, görsel üretim).
• Önbellek (opsiyonel): sıcak okuma (konuşma özetleri, embedding metadata), her zaman versiyonlar/zaman damgaları ile anahtarlanmış.

Not: Bunu tutarlı tutmanın pratik bir yolu, arka uç yığını erken standardize etmektir. Örneğin, Koder.ai tarafından üretilen arka uçlar sıklıkla Go ile PostgreSQL (ve ön uçta React) kullanır; bu, yetkili durumu SQL'de merkezileştirirken istemci önbelleğini geçici tutmayı kolaylaştırır.

Önce durum modelinizi tasarlayın

Ekranları inşa etmeden önce her katmanda dayanacağınız alanları tanımlayın:

• ID'ler ve sahiplik: user_id, org_id, conversation_id, message_id, request_id.
• Zaman damgaları ve sıralama: created_at, updated_at ve mesajlar için açık bir sequence.
• Durum alanları: queued | running | streaming | succeeded | failed | canceled (işler ve araç çağrıları için).
• Sürümleme: çakışma güvenli güncellemeler için etag veya version.

Bu, UI'ın “doğru göründüğü” ama yeniden deneme, yenileme veya eşzamanlı düzenlemelerle uyuşmazlık yaşadığı klasik hatayı önler.

Tutarlı API şekilleri kullanın

Özellikler arasında uç noktaları öngörülebilir tutun:

• GET /conversations (liste)
• GET /conversations/{id} (al)
• POST /conversations (oluştur)
• POST /conversations/{id}/messages (ekle)
• PATCH /jobs/{id} (durum güncelle)
• GET /streams/{request_id} veya POST .../stream (akış)

Her yerde aynı zarf stilini (hatalar dahil) döndürün ki ön uç durumu uniform şekilde güncelleyebilsin.

Durum bozulabileceği yerlerde gözlemlenebilirlik ekleyin

Her AI çağrısı için bir request_id loglayın ve döndürün. Araç çağrılarını (kırpma ile) girdiler/çıktılar, gecikme, yeniden denemeler ve nihai durumla kaydedin. “Model ne gördü, hangi araçlar çalıştı ve hangi durumu kaydettik?” sorusuna kolay yanıt verebilmelisiniz.

İnşa kontrol listesi (yaygın durum hatalarından kaçınmak için)

• Arka uç gerçek kaynaktır; ön uç önbelleği açıkça etiketlenmiş ve geçicidir.
• Her yazma idempotent (yeniden denemeye güvenli) request_id (ve/veya Idempotency-Key) ile.
• Durum geçişleri açık ve doğrulanmış (hiçbir zaman sessizce queuedten succeedede atlama yok).
• Akışlı güncellemeler ID/sequence ile birleştirilir, “son mesaj kazanır” değil.
• Çakışmalar version/etag veya sunucu tarafı birleştirme kuralları ile ele alınır.
• Kişisel tanımlayıcı bilgiler ve sırlar asla istemci durumunda saklanmaz; logları varsayılan olarak kırpın.
• Hata ayıklama için tek bir gösterge paneli var: istekler, araç çağrıları, iş durumu ve hatalar.

Daha hızlı inşa döngülerini (AI destekli üretim dahil) benimsediğinizde, bu kontrol listesi öğelerini otomatik zorlayan guardrail'lar eklemeyi düşünün—şema doğrulama, idempotency ve olaylı akış gibi—böylece “hızlı hareket etmek” durum kaymalarına yol açmasın. Pratikte, bu noktada Koder.ai gibi uçtan uca bir platform işinizi hızlandırabilir: teslimatı hızlandırırken, durum işleme kalıplarını web, arka uç ve mobil yapılar arasında tutarlı tutmanıza yardımcı olur.