Sunucu Donanım Yapılandırmaları | Modern Veri Merkezi Rehberi

Sunucu Donanım Yapılandırmaları | Modern Veri Merkezi Rehberi

Yazar

Ayberk Tığlı

Yayınlanma Tarihi
3 Haziran 2026
Görüntüleme

Modern Mimari Kavgasında Safımızı Seçiyoruz: Stateless mı, Stateful mu?

Yazılım dünyasında bazı kavramlar vardır ki; her gün kullanırız ama işin "felsefesini" konuşmaya pek vakit bulamayız. Bugün, modern web mimarisinin kalbinde yatan, ölçeklenebilirliğimizi belirleyen ve bazen uykularımızı kaçıran o meşhur ikiliyi masaya yatırıyoruz: Stateless (Durumsuz) ve Stateful (Durumlu) yapılar.

Eğer bir sistem tasarlıyorsanız, bu iki yaklaşımdan birini seçmek zorunda değilsiniz, aslında sistemin hangi parçasına hangisini giydireceğinize karar vermek zorundasınız. Hadi, lafı dolandırmadan bu iki mimarinin ruhuna inelim.

1. Belleği Olmayan Bir Dünya: Stateless Mimari

Stateless mimariyi en basit haliyle şöyle düşünebilirsiniz: Her istek (request), sanki o sunucuyla ilk kez konuşuyormuşsunuz gibi başlar ve biter. Sunucu, bir önceki adımda ne yaptığınızı hatırlamaz. Sizden gelen her paket, kendini açıklayan tüm bilgileri içinde taşımak zorundadır.

Neden Stateless?

Bugün kullandığımız modern, bulut tabanlı sistemlerin %90'ı neden Stateless üzerine kurulu? Çünkü özgürlük sağlıyor.

  • Sonsuz Ölçeklenebilirlik: Sunucunuzun yükü mü arttı? Yanına 10 tane daha sunucu ekleyin. Gelen istek hangi sunucuya giderse gitsin fark etmez, çünkü sunucunun içinde kullanıcıya dair özel bir bilgi (session vb.) tutulmuyor.
  • Hata Toleransı: Bir sunucu çökerse üzülmeyiz. Hemen trafiği diğerine yönlendiririz. Kullanıcı "Eyvah, sepetim boşaldı!" demez, çünkü sepet bilgisi zaten sunucunun belleğinde değil, ya istemci tarafında ya da merkezi bir veritabanındadır.

Madalyonun Diğer Yüzü

Tabii ki bedava yemek yok. Stateless yapıda her istekle beraber tüm yetkilendirme (auth) ve gerekli verileri taşımak, ağ trafiğini bir nebze artırabilir. Ayrıca, her seferinde veritabanına gidip "Bu kullanıcı kimdi?" diye sormak, doğru optimize edilmezse performans darboğazı yaratabilir.

Bakınız: [JWT (JSON Web Token) ile Kimlik Doğrulama]

2. Her Şeyi Hatırlayan Dost: Stateful Mimari

Stateful mimari, klasik ve "tanıdık" olandır. Sunucu, sizinle kurduğu iletişimin geçmişini tutar. Bir login olduğunuzda, sunucu belleğinde (RAM) size bir yer açar ve "Tamam, bu Ahmet, az önce şu ürüne baktı" der.

Ne Zaman Stateful Kullanırız?

  • Gerçek Zamanlı Sistemler: Online oyunlar veya borsa ekranları gibi milisaniyelerin kritik olduğu yerlerde, her seferinde "Ben kimim?" diye sormak çok yavaştır. Bağlantı bir kez kurulur (Persistent Connection) ve akış başlar.
  • Karmaşık İşlem Akışları (Workflows): Çok adımlı, birbirine sıkı sıkıya bağlı işlemlerde durumu sunucuda tutmak bazen geliştirme maliyetini düşürür.

Stateful’un Çıkmaz Sokakları

Stateful sistemleri ölçeklemek tam bir kabustur. Eğer kullanıcı "Sunucu A" üzerinde bir session açtıysa, bir sonraki isteği mutlaka "Sunucu A"ya gitmelidir. Buna biz Sticky Session (Yapışkan Oturum) diyoruz. Sunucu A çökerse? Geçmiş olsun, kullanıcının tüm oturum verisi uçar.

3. Teknik Karşılaştırma: Hangisi Sizin İçin?

Aşağıdaki tablo, projenizin geleceğini çizerken size rehberlik edebilir:

Özellik

Stateless

Stateful

Veri Saklama

İstemci (Client) veya DB

Sunucu Belleği (RAM)

Ölçeklenebilirlik

Çok Kolay (Horizontal Scaling)

Zor (Vertical Scaling/Sticky Session)

Bağımlılık

Sunucular arası bağımsızlık

Sunucuya bağımlı oturum

Hata Yönetimi

Kolay (Sunucu feda edilebilir)

Zor (Veri kaybı riski yüksek)

Karmaşıklık

Mimari düzeyde yüksek

Başlangıçta düşük

4. Gerçek Hayattan Bir Senaryo

Bir e-ticaret sitesi düşünelim.

Stateful Yaklaşım: Kullanıcı sepete ürün ekler. Sunucu bunu RAM'deki bir Session nesnesine yazar. Kullanıcı ödeme sayfasına geçtiğinde sunucu bellekten bu bilgiyi okur. Eğer o sırada sunucuya restart atılırsa, sepet buhar olur.

Stateless Yaklaşım: Kullanıcı sepete ürün eklediğinde, bu bilgi ya tarayıcıdaki bir Cookie içinde tutulur ya da merkezi bir Redis sunucusuna yazılır. Web sunucusu sadece bir aracıdır. Sunucu yansa da, yeni gelen sunucu Redis'e bakıp "Ha, sepet buymuş" der ve işleme devam eder.

Bakınız: [Dağıtık Önbellekleme (Distributed Caching) Stratejileri]

5. Hibrit Bir Dünya: En İyisini Seçmek

Aslında günümüzde "saf" bir Stateless yapıdan bahsetmek zordur. Veritabanları doğası gereği Stateful'dur (veriyi tutarlar). Bizim hedefimiz, Application Layer (Uygulama Katmanı) dediğimiz kısmı olabildiğince Stateless tutmaktır.

Eğer mikroservis mimarisine geçiş planlıyorsanız, Stateless sizin tek çıkış yolunuzdur. Docker konteynerlarının her an ölüp yeniden dirildiği bir dünyada, bir konteynerin belleğine güvenmek, kumdan kale yapmaya benzer.

Sonuç: Karar Anı

Özetlemek gerekirse; eğer projeniz "hızlı büyüsün, dünya çapında binlerce kullanıcıya hizmet versin, bir sunucu çöktüğünde sistem bana mısın demesin" diyorsanız, rotanız Stateless.

Ancak, çok spesifik bir ihtiyacınız varsa, örneğin düşük gecikmeli (low-latency) bir oyun motoru veya yoğun bir veri akışı yönetiyorsanız, Stateful yapının nimetlerinden (ve zahmetlerinden) faydalanabilirsiniz.

Mimari bir tercih yaparken kendinize şu soruyu sorun: "Eğer bu sunucuyu şu an fişten çekersem, kullanıcı her şeye baştan başlamak zorunda kalır mı?" Cevabınız evet ise Stateful, hayır ise Stateless dünyasındasınız.

Bir sonraki teknik yazımızda görüşmek üzere. Kodunuz hatasız, request’leriniz Stateless olsun!