Geçen yıl, Şubat 2025’te İstanbul’da bir girişim ekibiyle otururken çok tanıdık bir cümle duydum: “Hafta sonu ürün patladı. Pazartesi faturayı görünce sevincimiz kaçtı.” Açık konuşayım — bunu ilk duyduğumda biraz abartı sandım. Sonra aynı senaryoyu farklı ekiplerde de bizzat gördüm. Klasik SaaS tarafında trafik artınca can sıkıcı oluyor; AI tarafında ise iş biraz daha serttir (ki bu çoğu kişinin gözünden kaçıyor). Çünkü burada sorun sadece sunucu yükü değil, token maliyeti diye sessizce büyüyen bir canavar da var. Sessizce, ta fatura gelene kadar.
İşin aslı şu ki yapay zekâ uygulamaları viral olduğunda alkış kadar panik de getiriyor. Mesela de Amazon Bedrock gibi kullanım bazlı faturalanan sistemlerde, tek bir Reddit gönderisi ya da X’te dönen kısa bir demo videosu faturayı şişirebiliyor — hani dakikalar içinde. Ben bunu 2024 yazında Berlin’deki bir bulut etkinliğinde dinlediğimde aklıma ilk gelen şey şu oldu: “Bunu hard rate limit ile kesmek kolay, ama kullanıcı deneyimini de duvara toslatırız.” İşte tam burada akıllı yavaşlama devreye giriyor.
Viral Trafik Güzel, Fatura Pek Değil
Bir startup için viral olmak normalde kutlama sebebi (evet, doğru duydunuz). Daha fazla kullanıcı, daha fazla kayıt, daha fazla veri… Hani klasik büyüme hikâyesi. Ama AI destekli ürünlerde denklem değişiyor — kökten. Çünkü her soru sadece bir HTTP isteği değil; arka planda vektör araması, bağlam toplama, model çağrısı. Çoğu zaman uzun token zinciri var, hepsinin ayrı bedeli var. Yani trafikteki her sıçrama doğrudan cebinizi etkiliyor.
Geçen ay Kadıköy’de görüştüğüm küçük bir SaaS ekibi bunu çok net anlattı. Uygulamaları günde birkaç yüz istek alırken gayet rahatlarmış. Sonra bir demo video yayılmış, trafik 30 katına çıkmış ve bedelini hemen hissetmişler. Aslında — dur bir saniye, önce şunu — ki bu tartışılır — söyleyeyim — problem yalnızca ölçek değil; yanlış anda yanlış kalite seviyesinde cevap vermek de ciddi itibar kaybı yaratıyor. Bu ne anlama geliyor? İkisi birden gelince iş çıkmaza giriyor.
Burada iki uç var: Ya sistemi kapatıp “429 Too Many Requests” diyorsun ya da biraz akıllıca davranıp kaliteyi düşürerek hizmeti ayakta tutuyorsun. Netflix’in internet zayıflayınca filmi tamamen kapatmaması gibi düşünün — görüntü 4K’dan 720p’ye iner ama içerik devam eder, izleyici orada kalır. AI uygulamasında da amaç bu olmalı: kusursuzluk yerine süreklilik. Çünkü kullanıcı kapıdan çıktı mı, geri getirmek çok daha pahalıya geliyor.
Peki neden?
Neden sert limit bazen yetmiyor?
Kendi deneyimimden konuşuyorum, Sert limitlerin teknik olarak temiz olduğu doğru. Sistem kendini korur, bütçe yanmaz, ekip rahatlar (evet, doğru duydunuz). Kağıt üstünde süper görünüyor. Pratikte? Kullanıcı açısından mesaj basit: “Uygulama çalışmıyor.” Viral anın tam ortasında bu cümle bayağı kötü duruyor — hem ürün için hem marka için.
Benzer şeyi 2023 sonunda kendi test ortamımda yaşamıştım. Ankara’daki küçük bir müşteri projesinde deneme amaçlı açılan bot birkaç saat içinde beklenenden çok daha fazla kullanıldı. Biz ilk refleks olarak rate limit koyduk. Evet, masraf kontrol altına girdi. Dönüş oranı da düştü. Kullanıcılar beklemek yerine çıkıp gitti — yani kazanılmış dikkat elimizden kaydı, sessizce (evet, doğru duydunuz)
Akıllı Çözüm: Kaliteyi Dinamik Olarak Kıs
Bu yaklaşımın en sevdiğim tarafı şu: sistemi kapatmıyorsun, sadece mod değiştiriyorsun. Derin RAG yerine sığ RAG’e geçiyorsun; büyük modeli her istek için çağırmak yerine hafif modele yöneliyorsun; uzun bağlam yerine kısa özet kullanıyorsun. Kulağa taviz gibi geliyor. Ama bazen taviz değil, iyi mühendisliktir (en azından benim deneyimim böyle). Gerçekten.
Aslında, Kaba anlatımla: Deep RAG modu toprağın derinine inip çok sayıda belge çıkarıyor; Shallow RAG ise yakın çevreden hızlıca malzeme topluyor. İlki daha kaliteli cevap veriyor ama pahalı ve ağır — ikincisi hızlı ve ucuz fakat hafızası kısalıyor. Bu ikisini trafik durumuna göre otomatik değiştirmek, bence baya işe yarayan bir hamle. Şaşırdım açıkçası, ilk kez uyguladığımda ne kadar pürüzsüz çalıştığına.
| Mod | Kullanılan Bağlam | Maliyet | Cevap Kalitesi | Kullanım Senaryosu |
|---|---|---|---|---|
| Deep RAG | 15 bin token civarı | Yüksek | Daha iyi | Düşük trafik / premium kullanıcı |
| Shallow RAG | 1-2 bin token civarı | Düşük | Kabul edilebilir | Pik trafik / kriz modu / viral anlar |
| Tam Kapanma | Sıfır işlem | Düşükten aşağısı yok! | Sıfır hizmet… | Acil durumlarda son çare |
AWS Tarafında Mantık Nasıl Kuruluyor?
Circuit breaker fikri neden güzel çalışıyor?
Circuit breaker mantığı elektrikten ödünç alınmış, basit. Sağlam bir fikir: — itiraz edebilirsiniz tabi — eşik aşılırsa akımı kes ya da azalt ki sistem yanmasın. Burada akım dediğimiz şey API çağrıları; Bedrock invocation sayısı ya da tahmini maliyet olabilir. CloudWatch alarm kurarsın, eşik geçilince SNS tetikler, Lambda çalışır ve AppConfig içindeki bayrağı değiştirir (ben de ilk duyduğumda şaşırmıştım). Hepsi bu kadar — ortada insan yok.
Çok konuştum, örnekle göstereyim. Bu konuyla ilgili Yapay Zekâ Her Şeyi Biliyorsa Neden Susar? yazımıza da göz atmanızı tavsiye ederim.
Bunu editör masasında ilk okuduğumda düşündüğüm şey şu oldu: “Bu aslında trafik ışığı gibi.” Yeşilde hızlanırsın, sarıda frene hazırlanırsın… kırmızıda direk durursun mu? Hayır. Amaç kırmızıya düşmeden kalitenin dozunu ayarlamak. Nüanslı ama önemli bir fark bu.
{
"alarm": "bedrock-cost-high",
"threshold": "$50/hour",
"action": "switch_rag_mode_to_shallow",
"feature_flag": "RAG_MODE"
}Küçük startup için bu yapı özellikle kıymetli çünkü ekip genelde az kişiyle çalışıyor. Kimse gece üçte faturaya bakıp manuel müdahale etmek istemiyor — haklılar da (bizzat test ettim). Enterprise tarafta ise mesele biraz başka; orada uyumluluk, gözlemlenebilirlik. Onay süreçleri devreye giriyor, işler biraz yavaşlıyor ama bu kaçınılmaz.
Küçük ekip ile kurumsal ekip aynı şeyi mi yapmalı?
Ne yalan söyleyeyim, Bence hayır. Aynı çekirdeği kullansalar bile operasyon biçimi farklı olmalı. Küçük ekipte otomasyon agresif olabilir; alarm gelir gelmez moda geçersin. Kurumsalda ise belki önce uyarı verir, sonra yarı otomatik geçiş yaparsın ve güvenlik ile finans ekiplerini bilgilendirirsin. Yani teknoloji aynı kalıyor ama çevresindeki ritim değişiyor. Epey değişiyor.
- Küçük startup: hızlı karar + düşük operasyon yükü + net bütçe koruması
- Büyüyen scale-up: metriklere bağlı kademeli geçiş + A/B gözlemleme + maliyet izleme
- Enterprise: onay akışı + loglama + denetim izi + bölgesel politika farkları
- Panik modu şart mı? Evet… ama kontrollü panik daha iyidir!
Tasarımın Güzel Tarafları Var Ama Kusursuz Değil
Bakın, Açık konuşayım — bu mimarinin en hoş yani zarif olması (en azından benim deneyimim böyle). Uygulamayı kapatmıyorsun, kaliteyi küçültüyorsun. Kullanıcı yine cevap alıyor, marka zarar görmüyor, bütçe de nefes alıyor. Peki bunu neden söylüyorum? Üç taraf da kazanıyor, en azından teoride. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Araya gireyim: Neyse, uzatmayalım; bu modelin eksikleri de var. Mesela yanlış eşikte gereksiz yere Shallow moda düşersen kaliteli kullanıcı deneyimini boşa harcarsın (ciddiyim). Tersi durumda ise maliyet kaçmaya devam eder (kendi tecrübem). Bir başka risk de alarm yorgunluğu — CloudWatch her ufak dalgalanmada çalarsa ekip kısa sürede umursamamaya başlar. Bu gerçekten oluyor, gördüm.
En iyi sistem, genelde en güçlü sistem değildir. Bazen en iyi sistem, krizde nazikçe küçülüp ayakta kalabilen sistemdir.
Bunu yerelde çalışan modellerde de görüyoruz aslında. Model büyük olsun diye her soruda en pahalı yolu seçmek gerekmiyor. Hatta geçenlerde “Yerelde Çalışan Yapay Zekâ” üzerine hazırladığım notlarda benzer mantığı tekrar gördüm: yük azalınca model sadeleşsin, yük artınca frene bassın. Mantık hiç değişmiyor. Hiç. yapay konusundaki yazımız yazımızda bu konuya da değinmiştik.
Ekipler İçin Pratik Uygulama Notları
Eğer böyle bir yapı kuracaksanız önce neyi optimize ettiğinizi net yazın: maliyet mi, gecikme mi, yanıt kalitesi mi? Üçünü aynı anda sonsuza kadar maksimize edemezsiniz — bu kısmı dürüstçe kabul etmek gerekiyor, erken kabul etmek daha iyi. Ben kendi projelerimde genelde dört seviye tanımlıyorum: tam kalite, hafif kalite, acil servis modu ve kapanma eşiği. Bu konuyla ilgili Vecstore mı Imagga mı? Görsel Aramada Asıl Fark Nerede yazımıza da göz atmanızı tavsiye ederim.
- Metrikleri belirle: Bedrock invocation count, tahmini ücret, ortalama gecikme. — bunu es geçmeyin
- Eşik değerlerini test et: çok erken tetiklemesin, çok geç kalmasın.
- Lambda’ya tek görev ver: bayrak değiştirip kenara çekilsin.
- Kullanıcıya açık mesaj göster: “Şu an hızlı moddayız” demek güven yaratır.
Peki hangi parçayı önce kurmalı?
Önce ölçümü kurmalısınız. Ölçmediğiniz şeyi yönetemezsiniz — bu cümle klişe gibi dursa da hâlâ doğru, maalesef. CloudWatch alarmınız varsa geri kalan parça domino taşı gibi gelir. En kritik nokta ise AppConfig güncellemesini atomik yapmak; yarım yamalak geçişler işleri karıştırır. Bunu atlayıp pişman olan ekip sayısı az değil. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Nerede İyi Çalışır, Nerede Süründürür?
💡 Sahadan not: Bu yaklaşım sohbet botları, doküman asistanları ve içerik üretim araçlarında çok iyi çalışıyor. Ama tıbbi karar destek sistemi ya da finansal risk motoru gibi alanlarda kalite düşüşünü daha sıkı sınırlar içinde tutmak gerekir.
Sohbet tabanlı ürünlerde sığ moda geçince kullanıcı çoğu zaman fark etmeyebilir bile. Çünkü beklenti zaten yüzde yüz doğruluk değildir; hızlı yanıt önemli olur, cevap geldi mi yeter. Gel gelelim hukuk ya da sağlık gibi alanlarda cevabın kısılması hemen hissedilir ve dikkat ister. Orada degrade stratejisini sadece hız üzerinden değil, güvenlik üzerinden de tasarlamak lazım. Bu kısmı atlamayın.
Bir arkadaşım Londra’da çalışan küçük bir B2B platformunda buna benzer yapı kurmuştu, 2024 sonbaharında. Onların hedefi büyüdüğünde sistemi korumaktı ve gerçekten de hafta sonu kampanyası sırasında maliyet artışı yaklaşık yüzde kırk gerilemişti. Ben duyunca şaşırmadım dersem yalan olur. Çoğu takım ilk refleks olarak sadece sunucuyu büyütüyor, token ekonomisini unutuyor. Tamamen.
Sıkça Sorulan Sorular
AWS’de graceful degradation ne demek?
Trafik veya maliyet yükseldiğinde uygulamayı tamamen kapatmak yerine hizmet kalitesini kontrollü şekilde azaltmak demek. Böylece sistem ayakta kalır ve kullanıcı tamamen boş dönmez.
AWS AppConfig neden kullanılıyor?
Aynılar arasında gerçek zamanlı konfigürasyon değiştirmek için kullanılıyor. Kod deploy etmeden feature flag güncelleyebildiğiniz için kriz anlarında çok işe yarıyor.
Deep RAG ile Shallow RAG arasındaki fark nedir?
Deep RAG daha fazla doküman parçasını alıp geniş bağlamla cevap üretir; Shallow RAG ise az sayıda parça ile hızlı ve ucuz çalışır. İlki kaliteli,ikincisi ekonomik tarafta güçlüdür.
Sert rate limit koymak yerine neden bunu tercih edeyim?
Sert limit kullanıcıyı direkt dışarı atar; graceful degradation ise onu içeride tutar. Bilhassa viral büyüme dönemlerinde dönüşümü korumak için daha iyi sonuç verir.
Kaynaklar ve İleri Okuma
Amazon CloudWatch Resmi Sayfası
AWS AppConfig Kullanıcı Rehberi
]]
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
