Geçenlerde bir junior mühendisin System Design mülakatından çıkışta yüzündeki şaşkınlığı fark ettim; “Anlattığım çözüm teoride harikaydı, neden yeterli bulunmadı?” diye sordu. O an anladım ki, mülakatlarda çizilen ideal mimarilerle, üretim ortamındaki acımasız gerçekler arasında ciddi bir uçurum var. System Design mülakatları, adayların karmaşık sistemleri tasarlama ve ölçeklendirme becerilerini ölçmek için tasarlanmıştır, ancak gerçek dünyadaki bir mimari tasarımın sadece buzdağının görünen yüzünü ele alır.
Bu yazıda, mülakat ortamında sunulan steril senaryoların, üretimde karşılaştığımız tozlu, gürültülü ve bazen tamamen mantıksız koşullara nasıl evrildiğini kendi saha tecrübelerimle anlatmak istiyorum. Bir mimariyi sadece “çalışır” hale getirmek değil, aynı zamanda operasyonel olarak sürdürülebilir, güvenli ve maliyet etkin kılmak da büyük önem taşır. Mülakatlarda genelde bu tür detaylar göz ardı edilirken, gerçek hayatta projenin kaderini belirler.
System Design Mülakatları: Neden Gerçeklikten Kopuk Hissediyoruz?
System Design mülakatlarında genellikle adayın temiz bir tahta üzerinde, baştan sona ideal bir sistem kurması beklenir. Bu süreçte ölçeklenebilirlik, yüksek erişilebilirlik, tutarlılık gibi temel prensipler ön plandadır. Ancak bu yaklaşım, çoğu zaman mevcut altyapılar, bütçe kısıtlamaları, insan kaynakları ve teknik borç gibi gerçek dünya faktörlerini dışarıda bırakır.
Benim 20 yıllık sistem ve yazılım tecrübemde gördüğüm şey, sıfırdan sistem kurma fırsatının çok nadir olduğudur. Genellikle var olan bir yapıyı iyileştirmeye, entegre etmeye veya göç etmeye çalışırız. Mülakatlar bu bağlamda, gerçek bir cerrahın ameliyata başlamadan önce steril bir ortamda maket üzerinde pratik yapmasına benziyor; temel prensipleri öğrenmek için harika ama gerçek bir hastanın vücudundaki beklenmedik durumları simüle etmiyor.
Örneğin, bir mülakatta “10 milyon kullanıcısı olan bir sosyal medya platformu nasıl tasarlarsınız?” sorusuna verilecek cevaplar genellikle microservice’ler, distributed cache’ler, sharding ve global load balancing gibi yüksek seviyeli mimari kalıplarını içerir. Bunlar elbette doğru yaklaşımlardır. Ancak aynı soruyu bir üretim ERP’si için sorsanız, yanıtlar tamamen değişir. Orada asıl sorun, mevcut bir monolitik yapının, eski bir veritabanının ve yıllarca birikmiş iş kurallarının getirdiği kısıtlamalarla nasıl başa çıkılacağıdır.
Mülakatlarda Ne Beklenir, Gerçek Hayatta Ne Karşılaşırız?
System Design mülakatları, adayın problemleri parçalara ayırma, bilinçli teknoloji seçimleri yapma ve ölçeklenebilirlik gibi temel kavramları anlama yeteneğini test eder. Genellikle adayın bir çözüm önermesi, bunu gerekçelendirmesi ve çeşitli senaryolara (yüksek trafik, veri kaybı vb.) nasıl tepki vereceğini açıklaması beklenir. Bu, teorik bilginin ve kavramsal düşünme yeteneğinin bir göstergesidir.
Gerçek hayatta ise durum çok farklıdır. Bir üretim ortamında karşılaştığım en büyük zorluklardan biri, sadece teknik kısıtlamalar değil, aynı zamanda organizasyonel ve kültürel faktörlerdir. Yeni bir özellik geliştirmeye çalışırken, mevcut bir legacy sistemle entegrasyon yapmak zorunda kalabilirim. Bu legacy sistem, yeni teknolojilerin sunduğu kolaylıkları sağlamaz ve hatta bazen kısıtlayıcı olur. Mülakatlarda “Yeni bir veritabanı seçin” denirken, gerçekte “Mevcut PostgreSQL 11 sürümünü optimize edin ve WAL bloat sorununu çözün” gibi görevlerle karşılaşırım.
graph TD
A["Mülakat Senaryosu"] --> B{"Problemi Anla"};
B --> C["Teknoloji Seçimi (İdeal)"];
C --> D["Ölçeklenebilirlik Çözümleri"];
D --> E["Yüksek Erişilebilirlik Stratejileri"];
E --> F["Tutarlılık Modelleri"];
F --> G["Temiz, Yeni Mimari"];
X["Gerçek Dünya Senaryosu"] --> Y{"Problemi Anla (Kısıtlarla)"};
Y --> Z["Mevcut Altyapı Analizi"];
Z --> AA["Bütçe ve Kaynak Kısıtlamaları"];
AA --> BB["Teknik Borç Yönetimi"];
BB --> CC["Operasyonel Gereksinimler"];
CC --> DD["Mevcut Sistemlerle Entegrasyon"];
DD --> EE["Pragmatik, Geliştirilmiş Mimari"];
Bu diyagram, mülakat senaryosu ile gerçek dünya senaryosu arasındaki temel farkı özetliyor. Mülakatlarda genellikle temiz bir başlangıç noktası varken, gerçek dünyada mevcut kısıtlamalar ve entegrasyonlar sürecin ayrılmaz bir parçasıdır. Örneğin, kendi yan ürünümün finansal hesaplayıcılarını geliştirirken, başlangıçta basit bir monolitik yapı kurdum. Ancak kullanıcı sayısı arttıkça ve yeni özellikler eklendikçe, mevcut yapının performans limitlerine ulaştığını gördüm. Bu noktada mülakatta “microservice’e geçin” demek kolaydır, ama ben mevcut monolitik yapıyı nasıl optimize edeceğimi, PostgreSQL’de index stratejilerini nasıl iyileştireceğimi ve Nginx’i nasıl bir reverse proxy olarak kullanacağımı düşündüm.
Trade-off’ların Sanatı: Kağıt Üzerinden Prodüksiyona
System Design mülakatlarının en önemli kısımlarından biri, teknoloji seçimlerinde ve mimari kararlarda yapılan trade-off’ları açıklayabilmektir. Örneğin, eventual consistency ile strong consistency arasındaki farkları bilmek ve hangi senaryoda hangisinin tercih edileceğini belirtmek beklenir. Ancak gerçek hayatta trade-off’lar çok daha karmaşıktır ve sadece teknik faktörlerle sınırlı değildir.
Bir e-ticaret sitesinin iç platformunda çalışırken, veritabanı replikasyon stratejisi seçerken sadece performans ve veri tutarlılığı düşünmedik. Aynı zamanda operasyonel yükü, mevcut ekibin PostgreSQL replikasyon deneyimini ve felaket kurtarma (disaster recovery) senaryolarında ne kadar hızlı ayağa kalkabileceğimizi de göz önünde bulundurduk. Logical replication bazı esneklikler sunarken, physical replication daha basit bir yönetim ve daha garantili bir veri bütünlüğü vaat ediyordu. Sonunda, ekibin deneyimi ve daha az operasyonel karmaşıklık nedeniyle physical replication’a yöneldik, çünkü olası bir replikasyon hatasında hızlıca müdahale edebilmek kritikti.
Bir başka örnek, bir mobil uygulama backend’i geliştirirken karşılaştığım durumdu. Kullanıcıların anlık mesajlaşma ihtiyaçları vardı ve bu, gerçek zamanlı bir sistem gerektiriyordu. Mülakatta WebSocket kullanmak ve Redis Pub/Sub ile ölçeklemek kolayca söylenebilir. Ancak ben mevcut bir HTTP tabanlı API’yi nasıl dönüştüreceğimi, Redis’in OOM eviction policy’sini nasıl seçeceğimi ve connection pooling’i nasıl optimize edeceğimi düşündüm. Özellikle Redis’te volatile-lru ile allkeys-lru arasındaki seçim, cache’in kritik verileri ne zaman atacağını belirledi ve yanlış bir seçim, ciddi performans düşüşlerine yol açabilirdi. Bu tür ince ayarlar, mülakatlarda genellikle es geçilen ama üretimde hayat kurtaran detaylardır.
Operasyonel Gerçekler: Ölçeklenebilirlik Sadece Kod Değildir
Mülakatlarda ölçeklenebilirlik denince akla hemen yatay ölçekleme (horizontal scaling), load balancer’lar ve distributed database’ler gelir. Bunlar elbette doğru yaklaşımlardır. Ancak gerçek dünyada ölçeklenebilir bir sistem inşa etmek, sadece mimari desenleri uygulamakla bitmez; operasyonel süreçlerin de ölçeklenebilir olması gerekir.
Bir üretim ERP’sinde çalışırken, AI ile üretim planlama modülünü devreye alıyorduk. Modülün kendisi gayet iyi ölçekleniyordu, ancak sorun, planlama sonuçlarının mevcut ERP’ye entegrasyonuydu. Bu entegrasyon, eski bir batch işleme mekanizması üzerinden yapılıyordu ve bu da darboğaz yaratıyordu. Modülün hızını artırmak için ne kadar çabalarsak çabalayalım, entegrasyon katmanı yüzünden genel sistem performansı sınırlı kalıyordu. Bu durumda, ölçeklenebilirlik sadece kodun değil, tüm sistemin ve hatta iş akışının bir özelliği haline geldi.
Sistem yönetimi tarafında, Linux servisleri ve container orkestrasyonu ile çalıştığım bir projede, memory limit’lerini ayarlarken çok dikkatli olmam gerekti. cgroup memory.high yumuşak limitini doğru belirlemek, uygulamaların beklenmedik OOM-killed olmasını engelleyebilirken, aynı zamanda sistemin genel stabilitesini koruyordu. Bir keresinde, sleep 360 komutuyla bir servisi geçici olarak beklemeye almıştım ve OOM-killed oldu çünkü systemd unit’indeki limitleri gözden kaçırmıştım. Bu durum, teorik bilgi kadar pratik deneyimin ve dikkatli yapılandırmanın ne kadar önemli olduğunu bir kez daha gösterdi. Journald rate limit’lerini ayarlamak, logların sistemi aşırı yüklemesini engellemek için kritik bir adımdı, aksi takdirde disk I/O’su darboğaz olabilirdi.
İnsan Faktörü ve Organizasyonel Akışın Rolü
Mülakatlarda mimariler genellikle soyut, insan faktöründen arındırılmış bir ortamda tasarlanır. Ancak gerçek projelerde, mimari kararlar sadece teknoloji değil, aynı zamanda o teknolojiyi kullanacak, yönetecek ve geliştirecek ekibin yapısıyla da yakından ilişkilidir. Yazılım mimarisi, çoğu zaman yazılımın kendisi değil, organizasyonel akışın bir yansımasıdır.
Bir bankanın iç platformunda, farklı ekiplerin farklı yetkinliklere sahip olduğunu gördüm. Bir ekip microservice’ler konusunda çok deneyimliyken, diğer bir ekip daha çok monolitik yapılar ve eski sistemlerle çalışıyordu. Bu durumda, her şeyin microservice olması gerektiğini savunan bir mimari, pratikte uygulanamaz hale geliyordu çünkü mevcut insan kaynağı bu değişimi kaldıramazdı. Mimariyi tasarlarken, ekibin mevcut yeteneklerini ve öğrenme eğrisini de hesaba katmak zorundaydım. Bu, bazen ideal teknolojik çözümlerden ödün vermek anlamına gelse de, projenin başarılı bir şekilde hayata geçirilmesi için elzemdi.
Kendi tecrübemde, bir sistemin güvenlik katmanlarını tasarlarken de benzer bir durum yaşadım. JWT/OAuth2 desenlerini uygulamak, teoride modern ve güvenli bir yaklaşımdır. Ancak bunu mevcut bir şirket yapısına entegre ederken, eski kimlik doğrulama sistemleriyle uyumluluk sağlamak ve IT ekibinin bu yeni modele adapte olmasını sağlamak zaman aldı. Güvenlik sadece teknik bir katman değil, aynı zamanda tüm organizasyonun bir kültürüdür. DHCP snooping, DAI, IP source guard gibi switch hardening tekniklerini uygularken, network ekibinin bu konulardaki bilgi seviyesi ve mevcut ağ topolojisinin karmaşıklığı, uygulama hızını ve şeklini doğrudan etkiledi.
Mülakatlardan Gerçek Mimariye: Ne Tür Bir Zihniyet Değişimi Gerekli?
System Design mülakatlarından edindiğimiz bilgiyi gerçek dünya mimarisine dönüştürmek için belirli bir zihniyet değişimi gerekiyor. Bu, “ne kadar ideal olursa o kadar iyi” düşüncesinden “ne kadar pragmatik ve sürdürülebilir olursa o kadar iyi” düşüncesine geçmek anlamına gelir. Mimarlar olarak sadece bir sistemin nasıl çalıştığını değil, aynı zamanda nasıl başarısız olabileceğini, nasıl bakımının yapılacağını ve zaman içinde nasıl evrileceğini de düşünmemiz şart.
Bu zihniyet değişimi, aşağıdaki temel prensipleri benimsemeyi içerir:
- Kısıtlamalarla Çalışma: Her zaman sıfırdan başlamayacağınızı kabul edin. Mevcut legacy sistemler, bütçe kısıtlamaları ve insan kaynakları gibi faktörleri tasarım sürecinin başlangıcında hesaba katın.
- Operasyonel Mükemmellik: Sadece geliştirme aşamasını değil, dağıtım (deployment), izleme (monitoring), hata giderme (debugging) ve bakım (maintenance) aşamalarını da planlayın. Bir sistemin sadece “çalışması” değil, “güvenilir bir şekilde çalışması” önemlidir.
- Esneklik ve Evrim: Tasarımlarınızın zaman içinde değişebileceğini ve evrilebileceğini unutmayın. Monolitik bir yapıyla başlayıp, ihtiyaç oldukça microservice’lere geçmek gibi esnek yaklaşımlar sergileyin.
- İletişim ve İşbirliği: Teknik çözümlerin yanı sıra, farklı ekiplerle ve paydaşlarla etkin iletişim kurma becerisi de bir mimarın en önemli araçlarından biridir. Mimari kararların ardındaki mantığı açıklamak ve uzlaşma sağlamak, projenin başarısı için kritiktir.
- Sürekli Öğrenme: Teknolojiler hızla değişiyor. PostgreSQL’in yeni sürümlerindeki özellikler, Redis’in yeni eviction politikaları veya kernel module blacklist’leri gibi güncel gelişmeleri takip etmek, mimari kararlarımızı daha bilinçli hale getirir.
Bir üretim ERP’sinde performans regresyonlarını izlerken, sadece kod değişikliklerine odaklanmak yerine, PostgreSQL’deki vakum ayarlarından, connection pool tuning’e kadar geniş bir yelpazede araştırma yapmayı öğrendim. Bu geniş bakış açısı, mülakatlarda edindiğimiz teorik bilginin ötesine geçerek, gerçek sorunları çözmemizi sağlıyor.
Sonuç
System Design mülakatları, mühendislerin teorik bilgilerini ve problem çözme yeteneklerini test etmek için değerli araçlardır. Ancak bu mülakatlardaki başarı, tek başına gerçek dünyada başarılı bir mimar olmak için yeterli değildir. Gerçek mimari tasarım, saf teknik bilginin ötesine geçerek, operasyonel gerçekler, bütçe kısıtlamaları, mevcut altyapı, insan faktörü ve organizasyonel akış gibi bir dizi karmaşık faktörü hesaba katmayı gerektirir.
Benim 20 yıllık tecrübemde öğrendiğim en önemli derslerden biri, “mükemmel” bir çözüm aramak yerine, “en uygun ve sürdürülebilir” çözümü bulmaya odaklanmaktır. Bu, bazen en güncel teknolojiyi kullanmamak, bazen de mevcut bir legacy sistemi akıllıca entegre etmek anlamına gelebilir. Mülakatlarda öğrendiğimiz teorik bilgileri, gerçek dünyanın kısıtları ve fırsatları ile harmanlayabildiğimizde, kağıt üzerindeki tasarımlarımız üretime hazır, dayanıklı ve başarılı mimarilere dönüşür. Bu dönüşüm, sadece teknik beceri değil, aynı zamanda pragmatizm, adaptasyon ve sürekli öğrenme gerektiren bir yolculuktur.