Bir startup’ta mimari toplantısında “tamamen stateless olalım” denilince kimse itiraz etmemişti. Yatay ölçekleme kolay olacaktı, deploy’lar risksizleşecekti, instance’lar dövüşebilirdi. Gerçekte ne oldu, state ortadan kalkmadı, sadece başka bir yere taşındı.
Stateless ifadesi bir aldatmaca barındırıyor. Uygulama sunucusu state tutmaz, doğru. Ama sistem bir bütün olarak state tutar. Redis, PostgreSQL, S3, Kafka, session store, rate limit store, feature flag store. Hepsi state. Sunucu stateless olunca state daha merkezi yerlere sıkışıyor ve o yerler darboğaz haline geliyor.
İlk proje: authentication için JWT kullandık. “Stateful session store’umuz yok” dedik, memnunduk. Sonra kullanıcı logout ettiğinde token’ı iptal etmek istedik. JWT kendiliğinden iptal olmuyor, süresi dolana kadar geçerli. Çözüm, iptal edilen token listesini Redis’te tutmak. Yani geri döndük, state burada. Üstelik her API çağrısı artık Redis’i ziyaret ediyor.
İkinci tuzak: caching. Stateless uygulama sunucusu tabii ki yerel cache kullanamaz, her instance farklı cache durumu tutamaz. Hepsi Redis’e veya Memcached’e gider. Peki cache sunucusu çökerse? Uygulama kaynak üreten bir DDoS’a dönüşür. Rate limiting için circuit breaker şart.
Üçüncü tuzak: rate limiting. “Kullanıcı başına dakikada 60 istek” diye sınır koymak istiyorsunuz. Stateless uygulamada bunu nerede sayacaksınız? Redis’te atomic increment + TTL. Yani yine Redis. Her istek Redis’e bir yazma daha ekliyor.
Dördüncü tuzak: uzun süreli işlemler. Kullanıcı bir upload başlatıyor, progress’i takip etmek istiyor. Stateless sunucu yapısında upload ID + Redis + polling zinciri kuruluyor veya WebSocket kullanılıyor. Ama WebSocket connection state tutar, sunucuya bağlıdır. Bu da sticky session veya pub/sub katmanı demektir.
Bir projemde microservice mimarisine geçişte fark ettik, aslında en yoğun trafik servisler arası değil, hepsinin Redis’e vuran trafik. Redis cluster darboğaz oldu. Çözüm, belirli state’i uygulama sunucusunda tutmak oldu. Yatay ölçekleme pahasına, ama o state (kullanıcı bağlamı) her zaman aynı instance’a gittiği için problem çıkmıyordu. Sticky session mantığıyla load balancer yönlendirdi.
Stateless düşüncesinin doğru yanı, uygulama mantığını state’ten ayırmak. Doğruyu yanlış bilen nokta, stateless olmanın bedava olduğunu düşünmek. State gitmiyor, başka yere geçiyor ve genellikle daha pahalı hale geliyor çünkü artık network üzerinden erişiliyor.
Pratik bir framework önerim var. Şu soruları sorun:
- Bu state zaten var mı, yoksa biz yaratıyor muyuz?
- Her istek için gerekli mi, yoksa sadece belirli flow’lar için mi?
- Kaybolursa ne olur?
- Latency bütçesi ne kadar?
Cevaplara göre state’in yerini belirleyin. Session gibi her isteği etkileyen state için merkezi store şart. Geçici computation state için in-memory uygun. Long-lived data için veritabanı. Türbülans yaratmayan state için sticky session mantıklı.
“Stateless” yanlış terim aslında. Doğrusu “share-nothing compute layer”. Uygulama sunucusu kendi arasında paylaşım yapmaz, bilgi database’lerde merkezi durur. Bu gerçekliği görünce mimari kararlar netleşiyor.