Sistem Tasarımı Nedir: Tek Sunucudan Milyonlara Ölçeklenen Fotoğraf Uygulaması

Bir fotoğraf paylaşım uygulaması düşün: kullanıcılar kaydolur, fotoğraf yükler, birbirini takip eder, takip ettiklerinin akışında gezinir. Kodu yazıp her şeyi tek bir sunucuya kurarsın ve uygulama kusursuz çalışır; ilk birkaç bin kullanıcıya tek sunucu rahatlıkla yeter, bütün veri ve fotoğraflar oraya sığar. Sonra günde 10 milyon kişi uygulamayı açmaya başlar ve fotoğraf yükleyen kod satırı değişmediği halde çözmen gereken sorunlar tamamen değişir: yüzlerce terabaytlık kullanıcı fotoğrafı nerede duracak, uygulamayı çalıştıran sunucu çökerse ne olacak, sunucu ABD'deyken Hindistan'daki kullanıcının akışı nasıl hızlı gelecek, popüler bir hesabın fotoğrafına bir milyon kişi aynı anda bakmaya kalkarsa ne olacak. Bunlar artık tek fonksiyonun içinde çözülmeyen, sistemin tamamının nasıl tasarlandığına bağlı sorunlardır.

Sistem tasarımı, bir sistemin hangi bileşenlere ihtiyacı olduğunu, her birinin neyden sorumlu olduğunu, birbirleriyle nasıl haberleştiğini ve verinin aralarında nasıl aktığını kararlaştırma sürecidir; amaç, sistemin gereksinimlerini karşılamasıdır. Kod yazarken fonksiyonlar, sınıflar, veri yapıları ve algoritmalar düşünülür; sistem tasarlarken sunucular , veritabanları , önbellekler , kuyruklar , depolama birimleri ve bunları bağlayan ağ düşünülür. Üstelik bileşenlerden biri yavaşladığında ya da çöktüğünde ne olacağı, trafik ve veri büyüdükçe davranışın nasıl değişeceği de hesaba katılır; yani tasarım, kodun bir üst katmanında işleyen bir düşünme biçimidir.

Gereksinimler: ne yapacak, ne kadar iyi yapacak?

Her tasarım gereksinimlerle başlar, çünkü sistemin ne yapması gerektiği bilinmeden tasarım değerlendirilemez. Gereksinimler iki gruba ayrılır: işlevsel gereksinimler sistemin ne yapacağını anlatır; fotoğraf uygulamasında kullanıcıların fotoğraf yükleyebilmesi, birbirini takip edebilmesi, gönderileri beğenip akışı görüntüleyebilmesi gibi. İşlevsel-olmayan gereksinimler ise bunları ne kadar iyi yapacağını anlatır; akışın 200 milisaniyenin altında açılması, bir sunucu çökse bile uygulamanın erişilebilir kalması, yüklenen fotoğrafların kaybolmaması gibi. İşlevseller hangi özellik, API ve bileşene ihtiyaç olduğunu belirler; işlevsel-olmayanlar bu bileşenlerin nasıl tasarlanacağını, ne kadar kapasite gerekeceğini ve arızaların nasıl karşılanacağını şekillendirir. Educative'in işlevsel ve işlevsel-olmayan gereksinimler anlatısı da aynı ayrımı vurgular: Educative'e göre bu ayrım sonraki tüm mimari kararların taslağıdır ve 100 kullanıcılı bir uygulamayla 100 milyon kullanıcılılı aynı özelliklere sahip olsa bile tasarımları tamamen farklı görünebilir.

Büyük sistemlerin çoğu, görece küçük bir ortak yapı taşı setinden kurulur. Mobil uygulama ve tarayıcı gibi istemciler isteği gönderir, DNS alan adını bir sunucu adresine çevirir, yük dengeleyici gelen istekleri birden çok uygulama sunucusuna dağıtır, uygulama sunucuları iş mantığını çalıştırır. Veritabanları kullanıcı, takip ve fotoğraf üstverisi gibi yapısal veriyi tutar; nesne depolama fotoğrafların kendisini saklar; önbellek sık okunan veriyi bellekte tutarak veritabanı yükünü azaltır; CDN statik içeriğin kopyalarını kullanıcıya yakın sunucularda tutar; mesaj kuyrukları hemen bitmesi gerekmeyen işleri arka plana taşıyarak kullanıcıyı bekletmez. Tasarımın özü, bu bloklardan hangilerine ihtiyaç olduğuna ve birlikte nasıl çalışacaklarına karar vermektir. Mehdi Akiki'nin yapı taşları haritası da her bloğu dört soruyla okumayı önerir: nedir, neden vardır, ne zaman ortaya çıkar, yanlış kullanılırsa ne bozulur; önbellek tekrarlanan okumalar pahalı olduğu için, kuyruk her işin istek hattında olmaması gerektiği için, CDN kullanıcılar sunuculardan uzakta olduğu için vardır.

Uçtan uca: bir fotoğrafın yolculuğu

Bu parçaların birlikte nasıl durduğunu fotoğraf uygulamasında izleyelim. Kullanıcı fotoğraf yüklemek istediğinde istek önce yük dengeleyiciden uygulama sunucularından birine gider; sunucu sahip, açıklama ve zaman damgası gibi üstveriyi veritabanına yazar, ardından uygulamanın görüntüyü doğrudan nesne depolamaya yüklemesine izin veren ön-imzalı bir adres üretir. Yükleme bitince sistem ek işlemler için kuyruğa bir iş bırakır; arka plan çalışanları bu işi alıp küçük resim üretme ya da takipçilerin akışını güncelleme gibi yavaş görevleri üstlenir. CodeSnatch'in nesne depolama ve CDN dersi bu modeli doğrular: CodeSnatch'e göre veritabanları büyük yapısız dosyalar için yanlış adrestir, S3 türü depolar on bir dokuzluk dayanıklılıkla ucuz ve sınırsız ölçeklenen alan sunar, ön-imzalı adresler istemcinin dosyayı doğrudan depolamaya yazmasını sağlar.

Okuma yönü aynı kutuları farklı kullanır. Başka bir kullanıcı akışını açtığında uygulama sunucusu önce gönderi listesi için önbelleğe bakar; veri orada yoksa veritabanından okur ve sonucu sonraki istekler için önbelleğe yazar. Görüntülerin kendisi CDN üzerinden, kaynağın kendisinden değil kullanıcının konumuna en yakın sunucudan gelir. Her bileşenin bir nedeni vardır: CDN gecikmeyi düşürür, kuyruk yavaş işi istek hattından uzak tutar, önbellek veritabanı yükünü azaltır, nesne depolama büyük dosyalar için ölçeklenen yer açar.

Nitelikler ve ödünleşimler

Bir tasarım değerlendirilirken bakılan yaygın nitelikler şunlardır: ölçeklenebilirlik , yani talep büyüdükçe daha çok kullanıcı, trafik ve veriyi kaldırma yetisi; erişilebilirlik , bazı bileşenler çökse bile sistemin ulaşılabilir kalması; güvenilirlik , veri kaybetmeden, çoğaltmadan ya da bozmadan doğru davranmayı sürdürmesi; performans , genelde gecikme ve birim zamanda işlenen istek sayısıyla ölçülür; tutarlılık , farklı kullanıcı ve servislerin verinin aynı güncel halini görmesi; bakım kolaylığı , sistemin işletilmesinin, hatalarının ayıklanmasının ve genişletilmesinin ne kadar rahat olduğu; ve son olarak maliyet , çünkü iyi tasarım gereksinimi gerekenden fazla sunucu, depolama, bant genişliği ve mühendislik emeğiyle karşılamamalıdır.

Bu niteliklerden birini iyileştirmek çoğunlukla başka yerde bir bedel ödetir. Önbellek eklemek veritabanı yükünü azaltır ve okumaları belirgin hızlandırır, ama önbellekteki veri bayatlayıp yenilenene ya da süresi dolana kadar güncel dışı kalabilir. Daha çok kopya ve yedeklilik performansı ve erişilebilirliği artırır, ama maliyeti yükseltir ve sistemi işletmesi daha karmaşık hale getirir. Her şeyde en iyi tek tasarım neredeyse yoktur; tasarım işinin büyük kısmı bu ödünleşimleri anlamak, kendi gereksinimlerin için hangi niteliklerin önemli olduğuna karar vermek ve bir yaklaşımı diğerine neden tercih ettiğini açıklayabilmektir.

Küçük başla, darboğazda büyüt, mülakatta anlat

Gerçek sistemler ilk günden son halleriyle kurulmaz. Fotoğraf uygulaması tek uygulama sunucusu ve tek veritabanıyla başlar; ilk birkaç bin kullanıcıya bu fazlasıyla yeter. Kullanım büyüdükçe farklı darboğazlar belirir: veritabanı zorlanır, görüntü sunumu yavaşlar, arka plan işleri kullanıcı isteklerini geciktirir; işte o noktada sorunu çözen bileşen eklenir: önbellek, CDN, okuma kopyaları ya da kuyruk. Hepsini erkenden eklemek, karşılığında değer almadan karmaşıklık, hata ayıklama yükü ve maliyet getirir. İyi tasarım bugünün gereksinimini karşılarken yarının ölçeğine yer bırakan tasarımdır.

Arka uçla çalışan herkes görece küçük özelliklerde bile tasarım kararı verir. Uygulamadaki beğeni düğmesini ele al: beğeni sayacı önbelleğe alınsın mı, sayaç güncellemesi istek içinde mi yapılsın kuyruğa atılıp arka planda mı işlensin, ünlü bir hesap paylaştığında milyonlar aynı anda etkileşime geçerse ne olacak? Tasarımı bilmek bu seçenekler arasında sağlıklı akıl yürütmeyi, bedelleri görmeyi ve bir yaklaşımın diğerinden neden daha mantıklı olduğunu açıklamayı sağlar.

Tasarım turu birçok teknoloji şirketinde orta ve üst düzey mühendisler için standart bir mülakat durağıdır; hatta bazı şirketler daha az deneyimli adaylara basitleştirilmiş sürümünü uygular. Buradaki performans işe giriş seviyesini etkileyebilir, bu da doğrudan ücrete yansır. Format genelde açıktır: adaya 45 dakika ile bir saat arasında süre verilir ve kısa bağlantı servisi, sohbet uygulaması ya da videodaki fotoğraf uygulaması gibi bir sistem tasarlaması istenir; tek doğru cevap yoktur, testleri geçen kod yazılması beklenmez. Aday videodakine benzer bir sırayı izler: gereksinimleri netleştirir, ölçeği tahmin eder, üst düzey taslak çizer, sonra veritabanı, önbellekleme, veri akışı ve arıza yönetimi gibi birkaç kritik alana iner; ilerlerken aldığı kararları ve arkasındaki bedelleri anlatır. TryExponent'in 2026 rehberi bu turun artık maliyet, hata durumları ve işletme muhakemesiyle geçildiğini yazar; InterviewLoop'un yedi adımlı çerçevesi de aynı sırayı önerir: netleştir, tahmin et, tasarla, derine in, bedelleri açıkla. Ortak ders şudur: yaygın tasarımları ezberlemeye gerek yoktur; yapı taşlarını, çözdükleri sorunları ve getirdikleri bedelleri bilen kişi daha önce hiç görmediği sistemler üzerine akıl yürütebilir.