System Design’ı Bir Oyun Alanıyla Anlamak
System Design’ı Bir Oyun Alanıyla Anlamak
System design kavramlarını ilk kez okumaya başladığınızda, her şey çok soyut görünebilir. “Database”, “Load Balancer” ya da “Microservices” gibi terimler kulağa karmaşık gelse de, aslında bunların temelinde çok basit sorunlara verilen çözümler vardır.
Bu yazıda, soyut kavramların ötesine geçip onları somutlaştıracağız. Bunu yaparken tek bir oyun alanı hayal edeceğiz. Bu oyun alanındaki oyuncaklar, görevli kişiler ve kurallar; bilgisayar sistemlerindeki yapıları temsil edecek. Yani her kavramı günlük hayatta karşılaştığımız basit bir oyun senaryosuyla ilişkilendireceğiz.
Amacımız teknik terimleri sadece ezberlemek değil, onların neden ortaya çıktığını ve hangi problemi çözdüğünü anlaşılır bir şekilde göstermek. Çünkü system design, karmaşık kavramların değil; doğru yerde kullanılan basit fikirlerin toplamıdır. Şimdi bu oyun alanına adım atalım ve kavramları sırayla keşfedelim.
🎡 Oyun Alanı Metaforu ile System Design
1. Client-Server Architecture: Düşün ki sen bir oyuncusun (client) ve oyuncak dolabına (server) oyuncak almak için gidiyorsun. Oyuncak dolabı sürekli çalışıyor, sen isteğini gönderiyorsun, dolap işini yapıp cevabı geri veriyor.
2. IP Address: Ama hangi dolaba gideceğini bilmen gerekiyor. İşte IP adresi, dolabın adresi gibi: nerede olduğunu gösteriyor.
3. DNS: Dolap adresini hatırlamak zor olabilir. DNS, “oyuncakdiyarı.com” gibi kolay isimleri dolabın gerçek adresine çeviren bir rehberdir.
4. Proxy / Reverse Proxy: Bazen isteğin direkt dolaba gitmez, arada bir görevli (proxy) isteğini alır ve doğru dolaba yönlendirir. Reverse proxy ise dolapları korur ve gelen oyuncuları dengeler.
5. Latency: Eğer dolap çok uzaksa oyuncak almak uzun sürer. Bu gecikme, sistemdeki veri iletim gecikmesine yani latency’ye benzer.
6. HTTP/HTTPS: Sen ve dolap, oyuncak alışverişi için belirli kuralları kullanırsınız. HTTP/HTTPS, bu kuralların protokolüdür.
7. APIs: API, dolapla konuşmanın bir yoludur. Oyuncu dolabı nasıl kullanacağını bilmek zorunda değil; sadece doğru API isteğini gönderir.
8. REST API: REST, API’nin basit kurallarla çalışmasını sağlar: GET ile alırsın, POST ile yeni oyuncak ekler, PUT/PATCH ile değiştirir, DELETE ile çıkarırsın.
9. GraphQL: GraphQL ise oyuncunun tam istediği oyuncakları almasını sağlar; gereksiz oyuncaklarla uğraşmaz.
10. Databases: Oyuncaklarını saklamak için büyük bir dolap gerekir. İşte database, oyuncakların güvenle saklandığı yerdir.
11. SQL vs NoSQL: Bazı dolaplar düzenli (SQL), bazıları hızlı ve esnek (NoSQL). Hangisini kullanacağın, oyunun ihtiyaçlarına bağlıdır.
12. Vertical Scaling: Dolap çok küçükse daha fazla raf ekleyebilirsin. Bu, tek bir makineyi güçlendirmek (RAM/CPU artırmak) gibidir.
13. Horizontal Scaling: Tek bir dolabı büyütmek yerine yanına birden fazla yeni dolap koyabilirsin. Yatay ölçekleme, sistemi daha güvenli ve güçlü yapar.
14. Load Balancer: Hangi oyuncu hangi dolaba gidecek? Load balancer, oyun alanına gelen oyuncuları dolaplara adil ve dengeli bir şekilde dağıtır.
15. Database Indexing: Dolap çok büyükse, oyuncakların tam olarak nerede olduğunu gösteren bir rehber (index) gerekir. Böylece aradığın oyuncağı binlerce katı aramadan hızlıca bulursun.
16. Replication: Bazı önemli oyuncakları birden fazla dolapta saklamak mantıklıdır. Dolaplardan biri bozulsa veya kırılsa bile oyuna diğer dolaplardan devam edebilirsin.
17. Sharding: Milyonlarca oyuncak varsa, hepsini tek bir dolaba koyamazsın. Oyuncakları harflerine veya türlerine göre tamamen farklı dolaplara bölersin.
18. Vertical Partitioning: Sorun sadece oyuncak sayısı değil, tek bir dolapta çok farklı türlerin bir arada olmasıdır. Türleri (örneğin sadece legoları ayrı, peluşları ayrı) dikey olarak farklı dolaplarda tutmak daha hızlı erişim sağlar.
19. Caching: Bazı oyuncaklar gün içinde çok sık kullanılıyorsa, onları en arkadaki büyük dolaptan çıkarıp kapının hemen yanındaki küçük, hızlı bir sepet içine (cache) koyabilirsin.
20. Denormalization: Bazı oyuncakları ve onlara ait aksesuarları normalde ayrı yerlerde durması gerekirken aynı dolapta saklamak işleri hızlandırır. Böylece aradığın seti bir kerede birleştirilmiş olarak bulursun.
21. CAP Theorem: Oyun alanında üç kural var: Oyuncaklar her zaman doğru yerde olmalı (Consistency), her an erişilebilir olmalı (Availability) ve dolaplar arasındaki bağlantılar kopsa bile oyun devam etmeli (Partition Tolerance). Ancak bu üç kuralın hepsini aynı anda %100 sağlamak mümkün değildir; duruma göre öncelik belirlemek gerekir.
22. Blob Storage: Bazı oyuncaklar çok büyüktür: Dev lego setleri veya devasa peluş filler gibi. Bunlar normal raflı dolaplara sığmaz, onlar için özel geniş depolar (blob storage) gerekir.
23. CDN: Oyuncaklar sadece ana depoda duruyorsa uzak köşedeki çocukların ona ulaşması uzun sürer. CDN, oyuncak