Bir sistemi tek sunucudan çıkarıp birden fazla bölgeye, veritabanına veya servise yaydığında ilk kazancın ölçeklenebilirlik olur. Ama sen de fark etmişsindir ki veri çoğaldıkça başka bir sorun doğar: aynı bilginin her yerde aynı kalması. Bu yazıda consistency kavramını, neden zorlaştığını, leader-follower yaklaşımını ve two phase commit protokolünü sade bir akışla ele alacağız.

Bir sistem büyüdükçe en kritik soru şuna dönüşür: Veritabanı çökerse ne olur? Bu yazıda tek veritabanlı bir mimarinin neden riskli olduğunu, Master-Slave replikasyonun bu riski nasıl azalttığını, okuma ölçeklendirmesini nasıl sağladığını ve işin Master-Master, split-brain, consensus, sharding gibi daha ileri konulara nasıl bağlandığını anlatacağız.

Veritabanlarında ölçeklenme deyince çoğu kişinin aklına önce daha güçlü makineler ya da daha fazla sunucu gelir. Ama bazen asıl mesele, verinin diske nasıl yazıldığıdır. Bu yazıda B+ Tree yaklaşımından başlayıp Log Structured Merge Tree yani LSM Tree yapısına kadar giden fikri adım adım kuracağız.

Bir chat uygulaması ilk bakışta “A kullanıcısı B kullanıcısına mesaj yollar” kadar basit görünür. Ama işin içine gerçek zamanlı iletişim, grup mesajlaşması, okundu bilgisi, son görülme ve ölçeklenebilirlik girince sistem tasarımı daha ilginç hale gelir. Bu yazıda WhatsApp benzeri bir uygulamanın temel mimarisini, servislerin görevlerini ve mesajların sistem içinde nasıl aktığını adım adım göreceksin.

Instagram gibi bir uygulamayı tasarlarken mesele sadece fotoğraf yüklemek değildir. Asıl zorluk, kullanıcıların birbirini takip ettiği, gönderilere yorum ve beğeni bıraktığı, milyonlarca kişiye kişiselleştirilmiş akış gösterilen bir sistemi ölçeklenebilir hale getirmektir. Bu yazıda Instagram benzeri bir sistemin temel veri modelini, servis mimarisini ve newsfeed üretme yaklaşımını Mermaid diyagramlarıyla adım adım kuracağız.