Kerangka Wawancara Desain Sistem
Pelajari kerangka RADIO lima langkah (Requirements, API, Data, Infrastructure, Optimise) dan berlatih menerapkannya pada pemendek URL
Kerangka Wawancara Desain Sistem adalah pelajaran DSA Interview Prep gratis di CoddyKit. Ini adalah pelajaran 1 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar DSA Interview Prep, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus DSA Interview Prep mencakup 4 pelajaran total.
Mengapa Desain Sistem Penting dalam Wawancara
Wawancara desain sistem menguji kemampuan Anda untuk berpikir dalam skala besar—bagaimana Anda akan merancang Twitter, YouTube, atau penyingkat URL untuk miliaran pengguna? Berbeda dari soal pemrograman yang memiliki satu jawaban benar, desain sistem bersifat terbuka: Anda harus membuat dan menjelaskan kompromi. Posisi senior dan tingkat staf mengalokasikan 30–45 menit khusus untuk sesi ini.
Pewawancara menilai apakah Anda dapat memperjelas persyaratan, memperkirakan beban, mengusulkan arsitektur tingkat tinggi, mendalami komponen utama, dan membahas kompromi—semuanya sambil berkomunikasi dengan jelas. Kerangka kerja yang terstruktur mencegah Anda berbicara tanpa arah dan memastikan semua aspek penting tercakup.
# 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)Ikhtisar Kerangka Kerja RADIO
Kerangka kerja RADIO menyediakan struktur 5 langkah yang dapat digunakan kembali untuk setiap wawancara desain sistem:
- R — Persyaratan: fungsional dan nonfungsional
- A — Desain API: operasi apa yang disediakan sistem?
- D — Model data: data apa yang disimpan dan bagaimana caranya?
- I — Infrastruktur: komponen tingkat tinggi (server, antrean, tembolok)
- O — Optimalkan: titik hambatan, penggunaan tembolok, pemecahan data, replikasi
Selalu ikuti langkah-langkah ini secara berurutan, tetapi kembali dan sempurnakan langkah sebelumnya ketika wawasan baru muncul. Alokasikan waktu yang kurang lebih sama untuk setiap tahap. Jangan pernah langsung menggambar kotak tanpa terlebih dahulu memperjelas persyaratan.
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')Langkah R: Memperjelas Persyaratan
Jangan pernah mulai merancang tanpa memperjelas persyaratan. Tanyakan tentang persyaratan fungsional (hal yang dilakukan sistem) dan persyaratan nonfungsional (skala, latensi, ketersediaan). Untuk penyingkat URL:
- Fungsional: memendekkan URL, mengarahkan ke URL asli, serta secara opsional mendukung alias khusus dan kedaluwarsa
- Nonfungsional: berapa banyak URL per hari? Apakah lebih banyak pembacaan atau penulisan? Persyaratan ketersediaan (99.9% atau 99.99%)? Latensi yang dapat diterima?
Menyatakan asumsi secara eksplisit menunjukkan kematangan. Pewawancara sering memberikan spesifikasi yang sengaja dibuat samar untuk melihat apakah Anda mengajukan pertanyaan yang tepat. Klarifikasi selama dua menit dapat mencegah Anda merancang sistem yang salah.
# 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)Langkah R: Estimasi Kasar
Setelah memperjelas persyaratan, perkirakan kapasitas. Ini menunjukkan bahwa Anda dapat menalar tentang skala sebelum mengusulkan solusi. Angka penting yang perlu diturunkan: permintaan per detik (RPS), penyimpanan yang diperlukan per hari/tahun, lebar pita, dan memori untuk penyimpanan dalam tembolok.
Gunakan angka bulat dan lakukan perkiraan secara bebas. Pewawancara memperhatikan orde besaran, bukan angka yang tepat. Contoh untuk penyingkat URL: 100M penulisan/hari ÷ 86400 ≈ 1160 penulisan/detik. 10B pembacaan/hari ÷ 86400 ≈ 115K pembacaan/detik. Setiap catatan URL ≈ 500 byte: 100M × 500B = 50 GB/hari, 18 TB/tahun.
# 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}')Langkah A: Desain API
Tentukan cakupan API—operasi yang disediakan sistem untuk klien dan layanan internal. Tentukan dengan jelas metode HTTP, jalur titik akhir, parameter permintaan, dan format respons. Hal ini menjadi landasan bagi seluruh desain: semua bagian lainnya ada untuk menerapkan API tersebut.
Untuk penyingkat URL, dua API inti adalah: (1) POST /shorten untuk membuat URL singkat, (2) GET /{alias} untuk melakukan pengalihan. Opsional: DELETE /{alias} untuk menghapus, GET /{alias}/stats untuk analitik. Tentukan kode respons (201 Dibuat, 301 Pengalihan, 404 Tidak Ditemukan).
# 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()Langkah D: Model Data
Model data menentukan data yang disimpan dan caranya. Identifikasi entitas inti beserta atributnya. Untuk penyingkat URL: tabel urls dengan alias (kunci utama), long_url, created_at, expires_at, dan user_id. Tabel clicks opsional untuk analitik.
Memilih jenis penyimpanan yang tepat sangat penting: basis data relasional untuk data terstruktur dengan kueri rumit; penyimpanan nilai-kunci (Redis, DynamoDB) untuk pencarian alias O(1) dalam skala besar; penyimpanan objek (S3) untuk data biner besar. Untuk penyingkat URL, penyimpanan nilai-kunci dengan alias sebagai kunci ideal untuk pembacaan, sedangkan basis data relasional digunakan untuk penulisan dan pengelolaan.
# 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')Langkah I: Infrastruktur Tingkat Tinggi
Gambarkan infrastruktur tingkat tinggi: server mana yang menangani tanggung jawab tertentu, bagaimana data mengalir di antara komponen, dan layanan eksternal apa yang digunakan. Untuk penyingkat URL dalam skala besar:
- Penyeimbang beban: mendistribusikan lalu lintas ke replika layanan penulisan dan pembacaan
- Layanan penulisan: menghasilkan alias, memvalidasi keunikan, menulis ke basis data, dan menghapus validitas tembolok
- Layanan pembacaan/pengalihan: memeriksa tembolok Redis terlebih dahulu, lalu menggunakan basis data jika data tidak ditemukan
- Basis data relasional: sumber kebenaran (dengan replika pembacaan)
- Klaster Redis: menyimpan pemetaan URL populer untuk pembacaan dalam waktu kurang dari satu milidetik
# 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)')Langkah O: Mengoptimalkan dan Menangani Titik Hambatan
Tahap pengoptimalan menangani titik hambatan dan meningkatkan skala sistem. Untuk penyingkat URL, perhatian utamanya adalah: latensi pengalihan (tempatkan Redis dekat pengguna dengan CDN atau tembolok tepi), keunikan alias dalam skala besar (gunakan server tiket terpusat atau fungsi hash dengan deteksi tabrakan), dan titik hambatan penulisan basis data (lakukan penulisan secara berkelompok atau asinkron dengan antrean).
Bahas kompromi secara eksplisit: pengalihan 301 mengurangi beban server tetapi mengurangi akurasi analitik; pengalihan 302 dapat dilacak tetapi menambah latensi. Tembolok dengan masa kedaluwarsa panjang mengurangi beban basis data, tetapi berisiko menyajikan URL yang usang. Menunjukkan bahwa Anda memahami ketegangan ini menandakan pola pikir tingkat senior.
# 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()Pembuatan Alias: Pengodean Basis62
Detail teknis inti penyingkat URL adalah cara menghasilkan alias yang singkat dan unik. Pendekatan standarnya adalah menggunakan ID bilangan bulat yang bertambah otomatis dari basis data dan mengodekannya dalam Basis62 (angka 0-9, huruf a-z, A-Z). String Basis62 sepanjang 7 karakter dapat mewakili 62^7 ≈ 3,5 triliun URL unik—cukup untuk beberapa dekade dengan 100M per hari.
Cara ini bebas tabrakan (setiap ID unik) dan menghasilkan string pendek yang aman untuk URL. Pemetaan ID→alias bersifat deterministik dan dapat dibalik. Komprominya: ID berurutan menghasilkan alias yang dapat diprediksi (kekhawatiran keamanan). Acak alfabet Basis62 atau gunakan offset penghitung untuk mengurangi keterprediksian.
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}')Menerapkan RADIO pada Desain Umpan Twitter
Mari kita terapkan RADIO secara singkat pada perancangan umpan berita mirip Twitter untuk menunjukkan bahwa kerangka kerja ini dapat diterapkan secara umum:
- R: Pengguna memposting twit, mengikuti pengguna lain, dan melihat umpan twit dari orang yang mereka ikuti. Skala: 300M pengguna, 500M twit/hari, umpan harus dimuat dalam <2 dtk.
- A:
POST /tweets,GET /feed,GET /timeline/{user_id} - D: tabel
tweets(id, user_id, content, created_at); tabelfollows(follower_id, followee_id); tembolok umpan untuk setiap pengguna - I: Layanan penyebaran menulis twit baru ke umpan pengikut (dihitung sebelumnya); Cassandra untuk tabel pengikutan/twit yang didominasi penulisan; Redis untuk tembolok umpan
# 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()Kesalahan Umum dalam Wawancara Desain Sistem
Hindari kesalahan umum berikut yang dapat menggagalkan wawancara desain sistem:
- Langsung mencari solusi: menggambar kotak sebelum memperjelas persyaratan menunjukkan kebiasaan rekayasa yang buruk
- Tidak membuat estimasi: merancang tanpa mengetahui skalanya sama saja dengan menebak
- Rekayasa berlebihan: merancang untuk 1 miliar pengguna ketika soal hanya menyebutkan 10.000 pengguna akan membuang waktu wawancara
- Tidak membahas kompromi: setiap pilihan memiliki kelebihan dan kekurangan; tidak menyebutkannya menunjukkan pemahaman yang dangkal
- Diam: pewawancara perlu mendengar proses berpikir Anda; jelaskan alasan di balik keputusan saat Anda membuatnya
# 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)Pemeriksaan Singkat
Uji pemahaman Anda tentang konsep Struktur Data & Algoritma — Persiapan Wawancara Pemrograman dari pelajaran ini.
Rangkuman Pelajaran
Dalam pelajaran ini Anda mempelajari: kerangka RADIO menyusun wawancara desain sistem menjadi Persyaratan, API, Model Data, Infrastruktur, dan Optimisasi, selalu perjelas persyaratan fungsional dan nonfungsional serta buat estimasi kapasitas sebelum mengusulkan desain, dan bahas kompromi secara eksplisit — setiap keputusan desain memiliki kelebihan dan kekurangan yang diharapkan dapat Anda jelaskan kepada pewawancara. Selanjutnya, kita akan membahas cara memilih antara mesin penyimpanan SQL dan NoSQL berdasarkan pola akses, konsistensi, dan skala.
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Kerangka Wawancara Desain Sistem” gratis?
Ya — teks lengkap “Kerangka Wawancara Desain Sistem” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus DSA Interview Prep, upgrade ke CoddyKit PRO. Kursus DSA Interview Prep mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Kerangka Wawancara Desain Sistem”?
Pelajari kerangka RADIO lima langkah (Requirements, API, Data, Infrastructure, Optimise) dan berlatih menerapkannya pada pemendek URL Kamu berlatih DSA Interview Prep dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai DSA Interview Prep?
Tidak diperlukan pengalaman sebelumnya. DSA Interview Prep di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 1 dari 4.
Berapa lama pelajaran “Kerangka Wawancara Desain Sistem” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran DSA Interview Prep ini?
Ya. Setiap pelajaran DSA Interview Prep menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Kerangka Wawancara Desain Sistem
- Penyimpanan Data Skalabel: SQL vs NoSQL
- Caching, CDN, dan Penyeimbangan Beban
- Merancang Pembatas Laju dan Merancang Feed Twitter