Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.
Cara menghadapi system design interview langkah demi langkah: requirements, estimasi scale, API dan data model, diagram, deep dive, trade-off, plus contoh pastebin.
Matthews Wong
Software Engineer
Ringkasan Utama
Untuk menghadapi system design interview langkah demi langkah, klarifikasi functional dan non-functional requirements, estimasi scale dengan aritmetika sederhana, definisikan API dan data model, gambar diagram high-level, deep dive komponen paling berisiko, lalu bahas bottleneck, failure mode dan trade-off sebelum menutup. Sebutkan asumsi dan beri angka pada setiap keputusan.
Kebanyakan orang yang macet di system design interview bukan kekurangan pengetahuan. Mereka kekurangan urutan kerja. Soal seperti design a pastebin memang sengaja dibuat terbuka, dan soal terbuka tanpa prosedur berakhir sebagai daftar nama teknologi yang dibacakan di depan whiteboard.
Saya perlu jujur soal otoritasnya. Saya menulis ini dari sisi kandidat, bukan dari kursi pewawancara, jadi tidak ada anekdot interview di bawah. Isinya checklist yang disusun dari literatur standar: definisi systems design, buku Google SRE, AWS Well-Architected Framework, dan Azure Architecture Guide. Contoh di akhir hanya memakai angka yang saya hitung langsung di depan Anda.
Framework ini adalah urutan tetap dari tujuh langkah. Setiap langkah menghasilkan sesuatu yang dipakai langkah berikutnya, sehingga melewatkan satu langkah membuat langkah sesudahnya kabur.
Definisi systems design di Wikipedia adalah proses mendefinisikan arsitektur, modul, interface dan data sebuah sistem agar memenuhi requirements yang ditentukan. Kalimat itu adalah framework ini dalam versi mini: requirements dulu, lalu interface dan data, baru arsitektur. Pewawancara memperhatikan apakah Anda bekerja ke arah itu, bukan apakah Anda sampai pada diagram tertentu.
Pakai beberapa menit pertama untuk bertanya, dan ucapkan asumsi Anda keras-keras kalau tidak ada yang menjawab. Tujuannya memisahkan soal menjadi functional requirements, yaitu fitur, dan non-functional requirements, yaitu kualitas yang menentukan arsitektur. Tabel berikut berisi pertanyaan yang paling berguna.
| Jenis | Pertanyaan yang diajukan | Apa yang berubah dari jawabannya |
|---|---|---|
| Functional | Siapa penggunanya dan apa dua atau tiga aksi intinya? | Permukaan API dan entity di data model |
| Functional | Apa yang jelas di luar scope: akun, search, edit? | Jumlah komponen yang digambar dan waktu untuk deep dive |
| Non-functional | Latency dan availability seperti apa yang diharapkan user? | Caching, replication, dan apakah satu node saja cukup |
| Non-functional | Apakah data basi boleh, dan berapa lama? | Consistency model, cache invalidation, read replica |
| Non-functional | Berapa user, berapa data, dan berapa lama disimpan? | Semua angka di langkah estimasi |
Buku Google SRE memberi kosakata untuk sisi non-functional: ia menyebut latency, availability dan throughput di antara indikator untuk menilai sebuah service, dan menyarankan target dinyatakan dalam percentile, bukan rata-rata. Pinjam itu. Mengatakan jalur baca harus menjawab di bawah 200 ms pada percentile ke-99 adalah requirement; mengatakan harus cepat bukan.
Pertanyaan yang layak diajukan di hampir semua soal:
Tulis requirements yang sudah disepakati di satu sudut papan dan biarkan di sana. Saat sampai di langkah trade-off, Anda menunjuk sebuah requirement, bukan membela selera.
Estimasi ada untuk memilih arsitektur, bukan menghitung tagihan. Post capacity estimation di seri ini membahas tekniknya lebih dalam; ringkasnya, bulatkan agresif, biarkan setiap asumsi terlihat, dan akhiri dengan empat angka: write per detik, read per detik, storage per tahun dan bandwidth. Kalau hasilnya selusin request per detik, Anda baru saja tahu bahwa satu node database bukan bagian yang sulit.
Pilih konstanta bulat sekali dan pakai terus. Satu hari ada 86.400 detik, yang dibulatkan jadi sekitar 100.000 saat butuh cepat. Traffic puncak adalah kelipatan dari rata-rata, dan dua sampai tiga kali adalah asumsi yang wajar selama Anda menyebutnya sebagai asumsi. Dua menit aritmetika ini mencegah sepuluh menit mendesain untuk scale yang salah.
Ini saran, bukan aturan. Panjang dan format interview berbeda-beda, dan pewawancara yang ingin menggali satu area akan menimpa jadwal apa pun yang Anda bawa. Pembagian di bawah adalah titik awal yang menurut saya masuk akal karena deep dive dan trade-off adalah tempat perbedaan antar kandidat terlihat.
| Langkah | Menit yang disarankan | Yang seharusnya sudah ada di papan |
|---|---|---|
| 1. Klarifikasi requirements | 5 | Daftar functional, target non-functional, di luar scope |
| 2. Estimasi scale | 5 | Request per detik, storage per tahun, bandwidth |
| 3. API dan data model | 7 | Endpoint dan satu atau dua tabel atau entity |
| 4. High-level design | 7 | Diagram kotak dan panah dengan jalur request |
| 5. Deep dive | 10 | Satu komponen dibahas mendalam |
| 6. Bottleneck dan trade-off | 7 | Failure mode dan harga tiap pilihan |
| 7. Tutup | 4 | Ringkasan satu menit dan langkah berikutnya |
Totalnya 45. Kalau Anda kehabisan waktu di high-level design, pendekkan deep dive, jangan lewati pembahasan failure; desain yang belum diuji lebih tidak berharga daripada desain dengan satu komponen yang digali tuntas.
Pernyataan trade-off punya tiga bagian: pilihannya, apa yang didapat, dan apa harganya. Kaitkan dengan requirement atau angka yang sudah Anda tulis. Frasa berikut menjaga diskusi tetap terstruktur dan tidak terdengar seperti selera pribadi.
Untuk failure mode, telusuri jalur request di diagram dan tanyakan apa yang terjadi saat tiap hop lambat, mati atau salah. Bab Google SRE tentang cascading failures menjelaskan kenapa lambat adalah kasus yang berbahaya: server overload yang menjawab lambat mengundang retry, dan retry menambah beban ke server yang sudah kesulitan. Post CAP theorem dan cache-aside di seri ini adalah bahan latihan yang bagus untuk sisi consistency dan staleness dari percakapan yang sama.
Jangan menjadikan retry satu-satunya jawaban untuk dependency yang gagal. Retry tanpa batas adalah cara yang terdokumentasi untuk mengubah dependency yang lambat menjadi outage penuh, jadi pasangkan setiap retry dengan batas, backoff dan cara untuk membuang load.
Tiga kesalahan menyumbang sebagian besar jawaban yang lemah, dan ketiganya soal urutan, bukan pengetahuan: menyebut tool terlalu cepat, melewatkan angka dan mengabaikan failure. Tabel memasangkan tiap kesalahan dengan wujudnya dan perbaikannya, ditambah dua kesalahan terkait.
| Kesalahan | Wujudnya | Perbaikan |
|---|---|---|
| Langsung menyebut nama teknologi | Kafka atau Redis muncul di menit pertama, sebelum ada yang tahu rasio baca | Jelaskan kebutuhannya dulu, misalnya buffer atau jalur baca cepat, baru sebut tool dan alternatif yang Anda tolak |
| Tanpa angka | Kata seperti scale besar, jutaan user, latency rendah tanpa angka di sampingnya | Jalankan langkah estimasi dan biarkan hasilnya menolak atau membenarkan tiap komponen |
| Mengabaikan failure | Diagram di mana semua kotak selalu berfungsi | Telusuri jalur request dan sebut apa yang dilakukan tiap hop saat lambat atau mati |
| Mendesain untuk scale yang salah | Sharding dataset yang muat di satu disk | Bandingkan estimasi dengan kemampuan satu node sebelum menambah mesin |
| Monolog tanpa jeda | Sepuluh menit tanpa memastikan requirements sesuai maksud pewawancara | Berhenti setelah tiap langkah dan tanyakan apakah perlu lebih dalam atau lanjut |
Perbaikan untuk kesalahan pertama paling murah dilatih: sebelum menyebut nama produk, selesaikan kalimat sistem ini butuh sesuatu yang melakukan X pada Y per detik. Kalau Anda tidak bisa mengisi Y, Anda melewatkan langkah dua.
Berikut seluruh framework diterapkan dari awal sampai akhir pada pastebin, service tempat user mengirim teks dan mendapat link pendek. Setiap angka di bawah adalah asumsi yang saya sebutkan, dan angka lainnya diturunkan dari asumsi itu. Tidak ada yang merupakan hasil pengukuran.
| Requirement | Keputusan atau asumsi |
|---|---|
| Functional: create | Kirim teks, terima link pendek |
| Functional: read | Buka link, lihat teksnya; waktu kedaluwarsa opsional |
| Di luar scope | Akun, edit, search, diff yang paham syntax |
| Non-functional: scale | Asumsikan 1 juta paste baru per hari, 10 read per write, rata-rata 10 KB, maksimum 512 KB |
| Non-functional: latency | Read di bawah 200 ms pada percentile ke-99 |
| Non-functional: availability dan retensi | Read tetap jalan saat satu node gagal; paste disimpan satu tahun |
Langkah dua adalah aritmetika. Hasilnya menunjukkan traffic kecil dan storage adalah sumbu pertumbuhan yang sebenarnya, yang memberi tahu di mana deep dive dipakai.
// Assumptions (stated aloud): 1M new pastes/day, 10 reads per write,
// 10 KB average body, 200 B metadata row, 1 year retention, peak = 3x average.
const SECONDS_PER_DAY = 86_400;
const writesPerSec = 1_000_000 / SECONDS_PER_DAY; // 11.6 -> call it 12
const readsPerSec = 10_000_000 / SECONDS_PER_DAY; // 115.7 -> call it 116
const peakWrites = 3 * writesPerSec; // ~35
const peakReads = 3 * readsPerSec; // ~350
const bodyBytesPerYear = 365_000_000 * 10_000; // 3.65e12 = 3.65 TB
const metaBytesPerYear = 365_000_000 * 200; // 7.3e10 = 73 GB
const readBandwidth = readsPerSec * 10_000; // ~1.16 MB/s average
// Key space: 7 base62 characters.
const keySpace = 62 ** 7; // 3_521_614_606_208 ~ 3.5e12
const fillAfter10y = 3_650_000_000 / keySpace; // ~0.001 -> 0.1% full
// Reading: ~350 reads/s at peak is one modest database node.
// The real growth axis is storage, so that is where the deep dive goes.Langkah tiga: sketsa API dan data model. Isi paste disimpan di object store, dan database hanya menyimpan satu baris metadata kecil yang menunjuk ke sana, karena metadata sekitar 200 byte sedangkan isinya sekitar 10 KB.
POST /v1/pastes
body: { "content": "...", "syntax": "plain", "ttl_seconds": 86400 } // ttl optional
201: { "id": "aZ3k9Qp", "url": "https://paste.example/aZ3k9Qp", "expires_at": "2026-10-11T08:00:00Z" }
413: content over 512 KB
429: create rate limit exceeded
GET /v1/pastes/aZ3k9Qp
200: { "id": "aZ3k9Qp", "content": "...", "syntax": "plain", "created_at": "..." }
404: unknown id
410: paste existed and has expired-- Metadata only. The body lives in the object store under blob_key.
CREATE TABLE pastes (
id char(7) PRIMARY KEY, -- base62; 62^7 ~ 3.5e12 keys
blob_key text NOT NULL, -- object-store key for the body
size_bytes integer NOT NULL CHECK (size_bytes BETWEEN 1 AND 524288),
syntax text NOT NULL DEFAULT 'plain',
created_at timestamptz NOT NULL DEFAULT now(),
expires_at timestamptz -- NULL = keep for the retention period
);
-- The expiry sweeper scans this; partial so non-expiring rows cost nothing.
CREATE INDEX pastes_expires_idx ON pastes (expires_at)
WHERE expires_at IS NOT NULL;
-- Random key + unique primary key: a collision fails the insert, the app retries with a new key.
-- Write this row LAST, after the body is stored, so a failure leaves an orphan blob, never a dangling row.Langkah empat, high-level design, singkat untuk soal ini: client berbicara ke web service stateless di belakang load balancer; service menulis metadata ke database relasional dan isi paste ke object store; read mengecek cache lebih dulu. Langkah lima memilih bagian paling berisiko, yang bukan throughput, karena satu database dengan mudah menangani sekitar seratus read per detik. Yang berisiko adalah pembuatan key dan pertumbuhan storage tanpa batas.
Untuk key, tujuh karakter base62 memberi sekitar 3,5 triliun nilai. Memilih key acak dan mengandalkan unique constraint berarti tabrakan saat insert diulang dengan key baru. Setelah sepuluh tahun paste, tabel baru terisi sekitar 0,1 persen, sehingga jumlah retry yang diharapkan tetap kecil sekali. Skema berbasis counter menghindari retry tetapi butuh counter yang terkoordinasi dan membuat key mudah ditebak, jadi sebutkan trade-off itu dan katakan mana yang Anda pilih serta alasannya.
Langkah enam dan tujuh. Bottleneck: storage bertambah sekitar 3,65 TB per tahun, jadi object store, bukan database, yang harus dipantau, dan expiry harus benar-benar menghapus isi. Failure mode: kalau cache mati, read jatuh ke database, yang sanggup menyerap load pada scale ini, jadi cache adalah optimisasi dan bukan dependency. Kalau penulisan ke object store sukses tetapi insert database gagal, Anda punya blob yatim, jadi tulis baris metadata terakhir dan sapu blob yatim secara berkala. Tutup dengan mengulang requirements dan menyebut langkah berikutnya: pencegahan abuse dan rate limiting pada endpoint create.
Empat menit terakhir adalah ringkasan singkat, bukan materi baru. Ulangi requirements dalam satu kalimat, sebut komponen yang Anda gali dan trade-off utamanya, dan daftar satu atau dua hal yang akan ditambahkan jika ada waktu. Sebagai pengecekan akhir, AWS Well-Architected Framework menawarkan checklist enam pilar: operational excellence, security, reliability, performance efficiency, cost optimization dan sustainability. Menanyakan pilar mana dari enam itu yang belum tersentuh adalah cara cepat menemukan celah.
Untuk berlatih, jalankan tujuh langkah pada satu soal per sesi, pasang timer, dan tulis angka sebelum diagram. Post lain di seri ini adalah latihan dengan alur pikir lengkap: mendesain URL shortener, post algoritma rate limiting, cache-aside versus write-through caching, dan CAP theorem dengan contoh praktis. Untuk awal yang lebih ringan, post system design explained for developers membahas dasarnya, dan Azure Architecture Guide adalah katalog architecture style dan design pattern yang layak dibaca sekilas untuk kosakata.
Aturan yang saya ambil dari semua ini adalah urutan mengalahkan kecerdikan. Bertanya sebelum menggambar, menghitung sebelum memilih, dan menyebut harga tiap pilihan. Desain sederhana dengan angka di baliknya dan failure mode yang disebut biasanya terbaca lebih baik daripada desain rumit yang tidak pernah menyebut bagaimana ia rusak.