Sistem Tasarımı: Ölçekleme, Parçalama ve Mimarın Seçimleri

Bir startup'ın API'si tek bir sunucuda çalışıyordu. Güzel işliyordu da, 50 milisaniye yanıt süresi, yüzde 99,9 çalışma süresi, mutlu müşteriler. Sonra ürün viral oldu. Bir haftada trafik üç katına çıktı. Ekip ilk tepkisini verdi: daha büyük bir sunucu al. Bir kez işe yaradı. İkinci trafiğin artışı sunucunun iki katı büyüklüğünü gerektirdi, sonra dört kat, sonra sekiz kat, ta ki hiçbir bulut sağlayıcı o kadar büyük bir makine satmayıncaya kadar. Şirketin en büyük trafik gününde sistem altı saat boyunca çöktü.

Bu, her ölçekleme hikayesinin çarptığı duvar: dikey ölçekleme (daha büyük sunucu) bir tavanı var, yatay ölçekleme (daha fazla sunucu) tavanı yok, ama başka bir mimariye gereksinim duyar. Tek bir makinedeki monolitik bir işlem olarak inşa edilmiş bir sistem, basitçe "dağıtılmış hale getirilemez". Kodun içine gömülü varsayımlar (paylaşılan bellek, yerel dosya sistemi, sıralı işlem) dağıtılmış ortamda çöker.

Yatay ölçekleme üç temel sorun çözer: yük dengeleme (trafiği sunucular arasında dağıt), veri tutarlılığı (tüm kopyaların senkronize kalması) ve bölümleme (verinin parçalarını farklı sunuculara koy). Ama her seçimin maliyeti var. Daha fazla sunucu, daha fazla ağ gecikmesi demek. Veri çoğaltma, tutarsızlık riski demek. CAP teoremi bunu basit kılar: tutarlılık, erişilebilirlik ve bölüm toleransından sadece ikisini seçebilirsin. Sosyal medya, erişilebilirliği seçer (biraz eski veriye katlanır). Banka, tutarlılığı seçer (bazen yavaş olsa da).

Mimarinizi tasarlarken sorunu çözmek için tasarla, sonradan ölçekle. Monolitten başlayan çoğu sistem, bölümlemeye geçer, ama bu geçiş, kodun temellerinden başlayarak tasarlanmadıysa acı verir.