Sistem Tasarımı Mülakatı Çerçevesi
Beş adımlı RADIO çerçevesini (Gereksinimler, API, Veri, Altyapı, Optimizasyon) inceleyin ve bir URL kısaltıcıya uygulama alıştırması yapın.
Sistem Tasarımı Mülakatı Çerçevesi, CoddyKit'te ücretsiz bir DSA Interview Prep dersidir. Bu, 4 dersinin 1. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, DSA Interview Prep öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. DSA Interview Prep kursu toplamda 4 dersten oluşur.
Mülakatlarda Sistem Tasarımı Neden Önemlidir
Sistem tasarımı mülakatları, büyük ölçekte düşünebilme becerinizi sınar: milyarlarca kullanıcı için Twitter, YouTube veya bir URL kısaltıcıyı nasıl tasarlardınız? Tek bir doğru yanıtı olan kodlama problemlerinin aksine sistem tasarımı açık uçludur; ödünleşimleri belirlemeli ve gerekçelendirmelisiniz. Kıdemli ve uzman düzeyindeki roller, yalnızca bu bölüme 30–45 dakika ayırır.
Mülakatçılar gereksinimleri netleştirip netleştiremediğinizi, yükü tahmin edip edemediğinizi, üst düzey bir mimari önerebildiğinizi, temel bileşenleri ayrıntılı inceleyebildiğinizi ve ödünleşimleri tartışabildiğinizi değerlendirir; bunların tümünü açık bir iletişimle yapmanız beklenir. Yapılandırılmış bir çerçeve, konudan konuya dağılmanızı önler ve tüm kritik boyutları ele almanızı sağlar.
# System design is not about a single correct answer.
# Interviewers look for:
eval_criteria = [
'Ability to clarify requirements before designing',
'Back-of-envelope capacity estimation',
'High-level architecture with clear components',
'Data modelling and storage choice',
'Handling scalability (10x, 100x load)',
'Trade-off discussion (consistency vs availability, etc.)',
'Communication: talking through decisions as you make them',
]
for c in eval_criteria:
print('-', c)RADIO Çerçevesine Genel Bakış
RADIO çerçevesi, her sistem tasarımı mülakatı için tekrarlanabilir 5 adımlı bir yapı sunar:
- R — Gereksinimler: işlevsel ve işlevsel olmayan
- A — Uygulama programlama arayüzü tasarımı: sistem hangi işlemleri sunar?
- D — Veri modeli: hangi veriler nasıl saklanır?
- I — Altyapı: üst düzey bileşenler (sunucular, kuyruklar, önbellekler)
- O — İyileştirme: darboğazlar, önbellekleme, parçalama, çoğaltma
Bu adımları her zaman sırayla izleyin; ancak yeni içgörüler ortaya çıktığında önceki adımlara dönüp onları geliştirin. Her aşamaya yaklaşık eşit zaman ayırın. Gereksinimleri netleştirmeden doğrudan kutuları çizmeye başlamayın.
RADIO = {
'R': 'Requirements — What must the system do? What scale?',
'A': 'API — Define endpoints/operations the system exposes',
'D': 'Data Model — Entities, schemas, storage types',
'I': 'Infra — High-level architecture: servers, queues, caches, CDN',
'O': 'Optimise — Identify and address bottlenecks, trade-offs',
}
for step, desc in RADIO.items():
print(f'[{step}] {desc}')
print('\nTiming guide for a 45-min interview:')
print(' R: 5 min | A: 5 min | D: 10 min | I: 15 min | O: 10 min')R Adımı: Gereksinimleri Netleştirme
Gereksinimleri netleştirmeden asla tasarlamaya başlamayın. İşlevsel gereksinimleri (sistem ne yapar) ve işlevsel olmayan gereksinimleri (ölçek, gecikme, kullanılabilirlik) sorun. Bir URL kısaltıcı için:
- İşlevsel: bir URL'yi kısaltma, özgün URL'ye yönlendirme, isteğe bağlı olarak özel takma adları ve sona erme süresini destekleme
- İşlevsel olmayan: günde kaç URL? Okuma ağırlıklı mı, yazma ağırlıklı mı? Kullanılabilirlik gereksinimi nedir (%99,9 mu, %99,99 mu)? Kabul edilebilir gecikme nedir?
Varsayımları açıkça belirtmek olgunluk gösterir. Mülakatçılar, doğru soruları sorup sormadığınızı görmek için çoğu zaman kasıtlı olarak belirsiz özellikler verir. İki dakikalık netleştirme, yanlış sistemi tasarlamanızı önler.
# Requirements questions for URL Shortener:
functional = [
'Shorten a given URL to a 7-character alias',
'Redirect short URL to original URL',
'Allow custom aliases (optional)',
'URL expiry (optional)',
'Analytics: click count per URL (optional)',
]
non_functional = [
'100 million new URLs per day (write: ~1160/sec)',
'10:1 read:write ratio => 11,600 redirects/sec',
'Redirects must be < 100ms p99 latency',
'99.99% availability (< 1 hr downtime/year)',
'URLs must be globally accessible',
]
print('Functional:')
for f in functional: print(' -', f)
print('\nNon-functional:')
for nf in non_functional: print(' -', nf)R Adımı: Kabaca Kapasite Tahmini
Gereksinimlerden sonra kapasiteyi tahmin edin. Bu, çözüm önermeden önce ölçek hakkında akıl yürütebildiğinizi gösterir. Çıkarılması gereken temel sayılar şunlardır: saniye başına istek (RPS), günlük/yıllık gereken depolama alanı, bant genişliği ve önbellekleme için bellek.
Yuvarlak sayılar kullanın ve yaklaşık hesaplamalar yapmaktan çekinmeyin. Mülakatçılar kesin rakamlarla değil, büyüklük mertebesiyle ilgilenir. Bir URL kısaltıcı örneği: günde 100 milyon yazma ÷ 86400 ≈ saniyede 1160 yazma. Günde 10 milyar okuma ÷ 86400 ≈ saniyede 115 bin okuma. Her URL kaydı yaklaşık 500 bayttır: 100 milyon × 500 bayt = günde 50 GB, yılda 18 TB.
# Back-of-envelope for URL Shortener
writes_per_day = 100_000_000 # 100 million URLs/day
read_write_ratio = 100 # 100:1 read/write
reads_per_day = writes_per_day * read_write_ratio
bytes_per_url = 500 # url string + metadata
years_to_store = 5
print('=== Capacity Estimation ===')
print(f'Writes/sec: {writes_per_day / 86400:.0f}')
print(f'Reads/sec: {reads_per_day / 86400:,.0f}')
print(f'Storage/day: {writes_per_day * bytes_per_url / 1e9:.1f} GB')
print(f'Storage total ({years_to_store}y): {writes_per_day * bytes_per_url * 365 * years_to_store / 1e12:.1f} TB')
cache_hit_rate = 0.80
hot_urls = reads_per_day * (1 - cache_hit_rate)
print(f'\n80% cache hit rate: {cache_hit_rate*100}% of reads from cache')
print(f'DB reads/sec: {hot_urls / 86400:,.0f}')A Adımı: Uygulama Programlama Arayüzü Tasarımı
Uygulama programlama arayüzü kapsamını, yani sistemin istemcilere ve dahili hizmetlere sunduğu işlemleri tanımlayın. HTTP yöntemini, uç nokta yolunu, istek parametrelerini ve yanıt biçimini açıkça belirtin. Bu, tasarımın geri kalanını temellendirir: diğer her şey bu arayüzleri uygulamak için vardır.
Bir URL kısaltıcı için iki temel arayüz şunlardır: (1) kısa bir URL oluşturmak için POST /shorten, (2) yönlendirme yapmak için GET /{alias}. İsteğe bağlı olarak: silmek için DELETE /{alias}, analiz için GET /{alias}/stats. Yanıt kodlarını belirtin (201 Oluşturuldu, 301 Yönlendirildi, 404 Bulunamadı).
# API Design for URL Shortener
apis = [
{
'method': 'POST',
'path': '/api/v1/shorten',
'request': '{"long_url": "https://...", "alias": "optional", "expires_at": "optional"}',
'response': '201 Created: {"short_url": "https://short.ly/abc1234", "alias": "abc1234"}',
},
{
'method': 'GET',
'path': '/{alias}',
'request': 'No body',
'response': '301 Redirect to long_url (or 404 Not Found)',
},
{
'method': 'GET',
'path': '/api/v1/{alias}/stats',
'request': 'Optional: date range query params',
'response': '200 OK: {"clicks": 42000, "unique_visitors": 15000}',
},
]
for api in apis:
print(f'{api["method"]} {api["path"]}')
print(f' Request: {api["request"]}')
print(f' Response: {api["response"]}')
print()D Adımı: Veri Modeli
Veri modeli, neyi ve nasıl sakladığınızı tanımlar. Temel varlıkları ve bunların özniteliklerini belirleyin. Bir URL kısaltıcı için: alias (birincil anahtar), long_url, created_at, expires_at ve user_id sütunlarını içeren bir urls tablosu. Analiz için isteğe bağlı bir clicks tablosu.
Doğru depolama türünü seçmek kritik öneme sahiptir: karmaşık sorgular içeren yapılandırılmış veriler için ilişkisel veritabanı; büyük ölçekte O(1) takma ad aramaları için anahtar-değer deposu (Redis, DynamoDB); büyük ikili nesneler için nesne deposu (S3). Bir URL kısaltıcı için takma ada göre anahtarlanmış bir anahtar-değer deposu okumalar açısından idealdir; yazma ve yönetim için ise ilişkisel bir veritabanı kullanılabilir.
# Data model for URL Shortener
# Core table (PostgreSQL)
urls_schema = '''
CREATE TABLE urls (
alias VARCHAR(16) PRIMARY KEY, -- e.g., 'abc1234'
long_url TEXT NOT NULL,
user_id UUID REFERENCES users(id),
created_at TIMESTAMP DEFAULT NOW(),
expires_at TIMESTAMP,
click_count BIGINT DEFAULT 0
);
CREATE INDEX ON urls(user_id);
'''
# Cache layer (Redis) for hot reads
redis_schema = '''
alias => long_url # O(1) GET on cache hit
TTL = 24 hours (or until expiry)
Cache eviction: LRU
'''
print('PostgreSQL schema:')
print(urls_schema)
print('Redis cache:')
print(redis_schema)
print('Storage split: Redis for hot reads (~80%), PostgreSQL for writes and cold reads')I Adımı: Üst Düzey Altyapı
Üst düzey altyapıyı taslak hâlinde gösterin: hangi sunucuların hangi sorumlulukları üstlendiğini, verilerin bileşenler arasında nasıl aktığını ve hangi dış hizmetlerin kullanıldığını belirtin. Büyük ölçekte bir URL kısaltıcı için:
- Yük dengeleyici: trafiği yazma ve okuma hizmeti kopyalarına dağıtır
- Yazma hizmeti: takma ad üretir, benzersizliği doğrular, veritabanına yazar ve önbelleği geçersiz kılar
- Okuma/yönlendirme hizmeti: önce Redis önbelleğini kontrol eder, bulunamadığında veritabanına geri döner
- İlişkisel veritabanı: tek doğruluk kaynağıdır (okuma kopyalarıyla birlikte)
- Redis kümesi: sık kullanılan URL eşlemelerini milisaniyenin altında süren okumalar için önbelleğe alır
# ASCII architecture sketch
architecture = '''
Clients
|
[Load Balancer]
/ \\
[Write API] [Read/Redirect API]
| | |
[Alias Gen] [Redis Cache]
| |
[PostgreSQL]---->[Read Replicas]
Alias Generation:
- Base62 encoding of auto-incrementing ID
- 62^7 = 3.5 trillion unique URLs (enough for 5 years at 100M/day)
- OR random 7-char Base62 with collision check
'''
print(architecture)
print('Key design decisions:')
print(' - Read/Write split: separate services for scalability')
print(' - Cache-aside pattern: read from Redis, fallback to DB')
print(' - 301 vs 302 redirect: 301 cached by browser (less load), 302 always hits server (analytics)')O Adımı: İyileştirme ve Darboğazları Ele Alma
İyileştirme aşaması darboğazları ele alır ve sistemi ölçeklendirir. Bir URL kısaltıcı için temel kaygılar şunlardır: yönlendirme gecikmesi (Redis'i CDN veya uç önbellekleriyle kullanıcılara yaklaştırın), büyük ölçekte takma ad benzersizliği (merkezi bir sıra sunucusu kullanın veya çakışma tespitiyle karma oluşturun) ve veritabanı yazma darboğazı (bir kuyrukla toplu ya da eşzamansız yazmalar yapın).
Ödünleşimleri açıkça tartışın: 301 yönlendirmeleri sunucu yükünü azaltır ancak analiz doğruluğunu düşürür; 302 yönlendirmeleri izlenebilir ancak gecikme ekler. Uzun sona erme süresine sahip önbellekleme veritabanı yükünü azaltır ancak güncelliğini yitirmiş URL'ler oluşturma riski taşır. Bu gerilimleri anladığınızı göstermeniz, kıdemli düzeyde düşündüğünüzü belirtir.
# Key optimisation discussion points
optimisations = {
'Read latency': [
'Redis cluster in multiple regions (CDN-edge caching)',
'301 redirect for non-tracked URLs (client caches)',
'302 redirect when click analytics are needed',
],
'Write throughput': [
'Async writes: accept request, enqueue to Kafka, batch-commit to DB',
'Ticket server (centralised ID generator) to avoid UUID collision',
'Or: hash(user_id + timestamp + random) with retry on collision',
],
'Availability': [
'Multi-AZ PostgreSQL with automatic failover',
'Redis Sentinel or Redis Cluster for HA cache',
'Health checks + circuit breaker on each service',
],
'Storage': [
'Partition urls table by hash(alias) for horizontal scaling',
'Archive expired URLs to cold storage (S3)',
],
}
for area, points in optimisations.items():
print(f'{area}:')
for p in points: print(f' - {p}')
print()Takma Ad Üretimi: Taban 62 Kodlaması
URL kısaltıcıların temel teknik ayrıntılarından biri, kısa ve benzersiz takma adların nasıl üretileceğidir. Standart yaklaşım, veritabanındaki otomatik artan bir tamsayı ID kullanmak ve bunu taban 62 ile kodlamaktır (0-9 rakamları, a-z ve A-Z harfleri). 7 karakterlik bir taban 62 dizesi, 62^7 ≈ 3,5 trilyon benzersiz URL'yi temsil edebilir; bu, günde 100 milyon hızla onlarca yıl için yeterlidir.
Bu yöntem çakışmasızdır (her ID benzersizdir) ve kısa, URL'lerde güvenle kullanılabilen dizeler üretir. ID→takma ad eşlemesi belirlenimlidir ve tersine çevrilebilir. Ödünleşim şudur: ardışık ID'ler tahmin edilebilir takma adlar oluşturur (güvenlik sorunu). Tahmin edilebilirliği azaltmak için taban 62 alfabesini karıştırın veya bir sayaç başlangıç kayması kullanın.
import string
BASE62_CHARS = string.digits + string.ascii_lowercase + string.ascii_uppercase
BASE = 62
def encode_base62(num):
if num == 0:
return BASE62_CHARS[0]
result = ''
while num:
result = BASE62_CHARS[num % BASE] + result
num //= BASE
return result
def decode_base62(s):
result = 0
for c in s:
result = result * BASE + BASE62_CHARS.index(c)
return result
# Generate aliases for IDs 1, 100, 1000, 10^9
for id_ in [1, 100, 1000, 1_000_000, 10**9, 3_521_614_606207]:
alias = encode_base62(id_)
decoded = decode_base62(alias)
print(f'ID {id_:20,} => alias "{alias}" (len={len(alias)}) => decoded={decoded}')RADIO'yu Mikroblog Akışı Tasarımına Uygulama
Çerçevenin genellenebilir olduğunu göstermek için RADIO'yu mikroblog tarzı bir haber akışı tasarımına kısaca uygulayalım:
- R: Kullanıcılar gönderi paylaşır, başkalarını takip eder ve takip ettikleri kişilerin gönderilerinden oluşan bir akış görür. Ölçek: 300 milyon kullanıcı, günde 500 milyon gönderi; akış 2 saniyeden kısa sürede yüklenmelidir.
- A:
POST /tweets,GET /feed,GET /timeline/{user_id} - D:
tweetstablosu (id, user_id, content, created_at);followstablosu (follower_id, followee_id); kullanıcı başına akış önbelleği - I: Yayma hizmeti yeni gönderileri takipçilerin akışlarına yazar (önceden hesaplanmış); yazma ağırlıklı takip ve gönderi tabloları için Cassandra; akış önbellekleri için Redis
# Fan-out on Write vs Fan-out on Read trade-off
fan_out_strategies = {
'Fan-out on Write (Push)': {
'How': 'When user A posts, immediately write to all followers feeds',
'Pro': 'O(1) feed read — feed is precomputed',
'Con': 'Celebrities with 10M followers => 10M writes per post; very slow write',
'Best for': 'Users with few followers (regular users)',
},
'Fan-out on Read (Pull)': {
'How': 'When user reads feed, query followees tweets and merge',
'Pro': 'Writes are fast (one DB write per tweet)',
'Con': 'Feed read is slow: must query all N followees',
'Best for': 'Celebrity accounts (few reads per post)',
},
'Hybrid': {
'How': 'Push for regular users, pull for celebrities',
'Pro': 'Balances read and write cost',
'Con': 'More complex implementation',
'Best for': 'Production systems like Twitter',
},
}
for strategy, details in fan_out_strategies.items():
print(f'{strategy}:')
for k, v in details.items(): print(f' {k}: {v}')
print()Sistem Tasarımı Mülakatlarında Yaygın Hatalar
Sistem tasarımı mülakatlarını sekteye uğratan şu sık yapılan hatalardan kaçınınız:
- Çözümlere hemen atlamak: gereksinimleri netleştirmeden kutular çizmek, kötü mühendislik alışkanlıklarına işaret eder
- Tahmin yapmamak: ölçeği bilmeden tasarım yapmak, tahminden öteye geçmez
- Aşırı mühendislik yapmak: soruda 10.000 kullanıcı denirken 1 milyar kullanıcı için tasarım yapmak, mülakat süresini boşa harcar
- Ödünleşimleri ele almamak: her seçimin artıları ve eksileri vardır; bunlardan bahsetmemek, konunun yüzeysel anlaşıldığını düşündürür
- Sessiz kalmak: mülakatçılar düşünme sürecinizi duymaya ihtiyaç duyar; kararlarınızı alırken gerekçeleriyle birlikte anlatınız
# Checklist: before you stop talking, verify you covered:
checklist = [
'[ ] Asked clarifying questions about scale and constraints',
'[ ] Made capacity estimates (RPS, storage, bandwidth)',
'[ ] Defined the API surface clearly',
'[ ] Described the data model and storage choices',
'[ ] Drew a high-level architecture with named components',
'[ ] Identified the main bottleneck and proposed a solution',
'[ ] Discussed at least one trade-off explicitly',
'[ ] Verified the design meets the stated requirements',
]
for item in checklist:
print(item)Hızlı Kontrol
Bu derste ele alınan Veri Yapıları & Algoritmalar — Kodlama Mülakatı Hazırlığı konularını ne kadar anladığınızı sınayınız.
Ders Özeti
Bu derste şunları öğrendiniz: RADIO çerçevesi, sistem tasarımı mülakatlarını Gereksinimler, API, Veri Modeli, Altyapı ve İyileştirme başlıklarına göre yapılandırır; bir tasarım önermeden önce işlevsel ve işlevsel olmayan gereksinimleri her zaman netleştirmeli ve kapasite tahminleri yapmalısınız; ayrıca ödünleşimleri açıkça ele almalısınız — her tasarım seçiminin artıları ve eksileri vardır ve mülakatçılar bunları ifade etmenizi bekler. Sırada, erişim kalıplarına, tutarlılığa ve ölçeğe göre SQL ile NoSQL depolama altyapıları arasında nasıl seçim yapılacağını inceleyeceğiz.
Sıkça Sorulan Sorular
“Sistem Tasarımı Mülakatı Çerçevesi” dersi ücretsiz mi?
Evet — “Sistem Tasarımı Mülakatı Çerçevesi” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve DSA Interview Prep kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. DSA Interview Prep kursu toplamda 4 dersten oluşur.
“Sistem Tasarımı Mülakatı Çerçevesi” dersinde ne öğreneceğim?
Beş adımlı RADIO çerçevesini (Gereksinimler, API, Veri, Altyapı, Optimizasyon) inceleyin ve bir URL kısaltıcıya uygulama alıştırması yapın. DSA Interview Prep ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.
DSA Interview Prep öğrenmeye başlamak için deneyim gerekli mi?
Önceden deneyim gerekmez. CoddyKit'te DSA Interview Prep, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 1. dersidir.
“Sistem Tasarımı Mülakatı Çerçevesi” dersi ne kadar sürer?
Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.
Bu DSA Interview Prep dersinde kod yazıp çalıştırabilir miyim?
Evet. Her DSA Interview Prep dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.
Bu kursun tüm dersleri
- Sistem Tasarımı Mülakatı Çerçevesi
- Ölçeklenebilir Veri Depolama: SQL ve NoSQL
- Önbelleğe Alma, CDN’ler ve Yük Dengeleme
- Hız Sınırlayıcı ve Twitter Akışı Tasarlama