System design interview adalah momen penting bagi kandidat dalam bidang tech untuk menunjukkan kemampuan arsitektural, trade-offs, dan komunikasi sistem desain skala besar.
Artikel ini memberi struktur belajar untuk teknologi informasi: konsep dasar, pola desain, evaluasi trade-offs, studi kasus chat service, serta latihan dan ceklis praktis agar pembaca siap menghadapi pertanyaan teknis nyata.
💻 Mulai Belajar Pemrograman
Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.
Daftar SekarangMemahami Konsep Dasar Arsitektur dan Scalability
Setiap sistem desain dimulai dari tujuan yang jelas. Biasanya kombinasi throughput (permintaan per detik), availability (waktu aktif), latency (waktu respons), consistency data, dan cost. Dalam wawancara, jelaskan angka konkret, misalnya target 1.000 RPS dengan p99 latency di bawah 300 ms.
Vertical scaling berarti memperbesar satu mesin: tambah CPU, RAM, atau disk. Horizontal scaling menambah banyak mesin lebih kecil di belakang load balancer. Gunakan vertical scaling untuk tahap awal serta sistem sederhana, lalu kombinasi horizontal scaling saat beban tumbuh dan butuh high availability.
Komponen umum arsitektur modern: client → load balancer → application server → cache → database, plus message queue untuk proses async dan CDN untuk konten statis. Jelaskan aliran data singkat, misalnya client ambil gambar dari CDN, tapi data user dari database.
Untuk database, sebutkan kapan memilih relational vs. NoSQL. Relational cocok untuk transaksi kuat, NoSQL untuk skala besar dan skema fleksibel. Replication meningkatkan read dan availability, sedangkan sharding atau partitioning membagi data ke banyak node agar beban tersebar.
Gambarkan perbedaan: arsitektur monolith seperti satu blok besar, semua fitur dalam satu deploy. Microservices memecahnya jadi banyak layanan kecil yang berkomunikasi lewat API atau message queue. Dampaknya, deployment lebih fleksibel, tetapi observability butuh tracing, metrics, dan logging yang matang.
Untuk contoh beban, kamu bisa mulai dari asumsi: 10 juta permintaan per hari ≈ 115 RPS rata-rata. Tambah faktor peak 5× sehingga desain untuk 600 RPS. Saat wawancara, tunjukkan cara menghitung kapasitas awal ini, lalu jelaskan proses scaling bertahap saat trafik naik.
Langkah Terstruktur untuk System Design Interview Sukses
Dalam system design interview, alurnya biasanya konsisten. Pertama, kamu melakukan requirement gathering. Selanjutnya, kamu menetapkan scope. Setelah itu, kamu menyampaikan high-level design. Kemudian, kamu masuk ke component deep dive, membahas trade-off, serta aspek scalability dan reliability. Terakhir, kamu menutup dengan rangkuman.
1) Requirement Gathering: Klarifikasi Tujuan
Pada awalnya, kamu perlu mengklarifikasi tujuan bisnis dan pengguna utama. Dengan begitu, kamu paham metrik apa yang paling penting. Misalnya, apakah fokusnya latency, throughput, atau konsistensi data.
2) Scope Definition: Batasi Masalahnya
Setelah tujuan jelas, batasi ruang lingkup agar solusi tetap fokus. Akibatnya, diskusi bisa selesai dalam waktu interview yang singkat. Selain itu, scope yang jelas mencegah kamu “terlalu cepat” masuk ke arsitektur.
Saat klarifikasi scope, biasakan bertanya hal yang spesifik, misalnya:
- SLA yang diharapkan (P95 latency, uptime)
- estimasi traffic per detik dan pola peak traffic
- proyeksi pertumbuhan data per hari atau per bulan
- skenario kegagalan yang paling kritis untuk bisnis
Pertanyaan ini menunjukkan kamu peduli pada kebutuhan nyata sistem. Jadi, kamu tidak hanya menggambar arsitektur yang terlihat rapi di papan.
3) Kapasitas: Asumsi dan Estimasi Sederhana
Berikutnya, gunakan templat jawaban yang terstruktur. Mulailah dari asumsi yang eksplisit. Lalu, lakukan estimasi kapasitas sederhana, seperti request per detik, ukuran data, dan kebutuhan storage. Dengan langkah ini, desainmu terlihat “berdasar,” bukan sekadar opini.
4) High-Level Design: Jelaskan Diagram Secara Verbal
Setelah estimasi, jelaskan high-level diagram secara verbal. Contohnya: klien, API gateway, service utama, database, cache, dan queue. Kemudian, jelaskan alur data dari ujung ke ujung. Terakhir, identifikasi potensi bottleneck dan cara mengatasinya.
5) Deep Dive dan Trade-off: Fokus Komponen Kunci
Selanjutnya, pilih 1–2 komponen paling penting untuk didalami. Misalnya, database schema, strategi caching, partisi data, atau desain message queue. Di bagian ini, tekankan trade-off secara ringkas. Contohnya, pilih konsistensi kuat vs ketersediaan, atau read latency vs kompleksitas.
6) Timeboxing: Contoh Alur 10–20 Menit
Untuk sesi 10–20 menit, kamu bisa memakai pembagian waktu berikut:
- menit 0–3: pahami kebutuhan dan tanya scope
- menit 3–7: sampaikan asumsi dan estimasi kapasitas
- menit 7–12: paparkan high-level design sambil menggambar diagram
- menit 12–17: deep dive komponen kunci dan bahas trade-off
- menit 17–20: rangkum solusi dan jawab follow-up singkat
Namun, tetap fleksibel sesuai arah pertanyaan pewawancara.
7) Komunikasi: Biar Pewawancara Mudah Mengikuti
Terakhir, latih komunikasi dengan pola yang konsisten. Sebutkan asumsi sebelum menghitung. Beri tahu kapan kamu akan menggambar diagram. Selain itu, gunakan istilah teknis yang ringkas. Contohnya: “di sini kita pakai cache untuk menurunkan read latency.”
Dengan cara ini, pewawancara lebih mudah mengikuti alur berpikirmu. Selain itu, mereka bisa menguji kedalaman pemahamanmu pada komponen dan pola desain yang kamu pilih.
Pola Desain Umum Komponen dan Konsistensi API
Dalam system design interview, pola seperti load balancing, caching, CQRS, event sourcing, circuit breaker, rate limiting, dan backpressure sering muncul.
Jelaskan kapan dipakai: misalnya caching untuk baca yang sering dan data relatif stabil, load balancing untuk sebar trafik, atau circuit breaker saat ada dependency yang tidak stabil. Tekankan juga trade-off: caching bisa menambah stale data, CQRS dan event sourcing menambah kompleksitas, tapi memberi skalabilitas dan audit trail.
Untuk desain API, sorot prinsip seperti idempotency pada endpoint pembayaran, versioning lewat /v1 atau header, pagination dengan limit dan kursor, serta error handling konsisten. Sertakan authentication dan authorization berbasis JWT atau OAuth2. Contoh singkatnya berikut.
|
1 2 3 4 5 6 7 8 9 |
POST /v1/payments Authorization: Bearer <token> Idempotency-Key: <uuid> { "user_id": "u_123", "amount": 150000, "currency": "IDR" } |
Jawaban bisa menyinggung perbedaan synchronous API (cepat terasa, tapi terikat latensi dan ketersediaan dependency) versus asynchronous berbasis queue atau event yang lebih tahan beban, tapi sering menimbulkan eventual consistency.
Jelaskan dampaknya ke pengalaman pengguna dan jadi jembatan ke diskusi trade-off antara latensi, konsistensi, serta biaya di bagian berikutnya.
Evaluasi Trade Off antara Latensi Konsistensi dan Biaya
Dalam sistem terdistribusi, kamu perlu mengukur hal yang dikorbankan. Metrik kunci: latency (sering dipantau sebagai p95/p99), throughput, availability, error rate, dan total cost of ownership (TCO). p95 berarti 95% permintaan selesai lebih cepat dari angka itu, sedangkan p99 mengungkap ekor lambat yang sering jadi masalah dalam produksi.
Untuk memilih trade-off, mulai dari critical path: alur yang langsung memengaruhi pengalaman pengguna atau uang bisnis. Lalu, tentukan toleransi konsistensi: apakah data harus strongly consistent atau boleh sedikit tertunda. Terakhir, cocokkan dengan SLA bisnis, misalnya 99,9% availability atau batas maksimum latency 300 ms.
Strong consistency cocok untuk use case seperti transaksi perbankan, yakni misalnya saldo tidak boleh salah meski 50 ms lebih lambat.
Eventual consistency cocok untuk news feed atau notification, yaitu sedikit keterlambatan update masih dapat diterima demi latency yang rendah dan throughput tinggi. Di lapangan, banyak sistem menggabungkan keduanya dalam bagian yang berbeda.
Dari sisi biaya, pertimbangkan biaya penyimpanan, bandwidth, compute, serta kompleksitas operasional dan waktu engineer. Misalnya, menambah replica di region lain menurunkan latency, tetapi menambah biaya sinkronisasi dan beban on-call. TCO yang sehat menyeimbangkan pengeluaran infrastruktur dengan produktivitas tim.
Untuk mitigasi, kamu bisa memakai caching layer, read replicas, dan graceful degradation saat dependensi lambat. Retries dengan exponential backoff membantu menurunkan error rate tanpa menimbulkan thundering herd. Pola-pola ini akan sangat relevan ketika kamu merancang layanan chat berskala besar dalam studi kasus berikutnya.
Studi Kasus Merancang Chat Service Skala Besar
Bayangkan kamu diminta merancang chat service real-time untuk jutaan pengguna. Requirement utamanya jelas: pesan harus tiba cepat, status online/offline akurat, ada delivery guarantee minimal at-least-once, riwayat pesan tersimpan, dan fitur seperti typing indicator.
Mulai dari user flow: login, membuka daftar percakapan, mengirim pesan 1:1 atau grup, sinkron antar perangkat, lalu logout. Dari sini kamu turunkan data model dasar: User, Conversation, Membership, Message, DeliveryReceipt, PresenceSession.
Untuk koneksi real-time, biasanya dipilih WebSocket di atas HTTP/2 atau HTTP/1.1 dengan load balancer yang mendukung sticky session. Pesan masuk ke chat gateway, lalu diteruskan ke message broker, seperti Kafka atau RabbitMQ untuk decoupling antara write path dan fan-out.
Status presence dan typing indicator cocok disimpan di in-memory store, seperti Redis karena butuh latensi sangat rendah. Riwayat pesan biasanya disimpan di NoSQL, seperti Cassandra atau DynamoDB, atau SQL yang di-shard berdasarkan conversation atau user id.
Skala jutaan pengguna menuntut sharding yang jelas. Umum dipakai pola user sharding: setiap pengguna dipetakan ke klaster gateway dan shard database tertentu menggunakan consistent hashing.
Untuk grup besar, kamu perlu memilih antara fan-out on write (tulis ke inbox tiap anggota saat pesan dibuat) atau fan-out on read (simpan sekali per conversation, lalu tiap klien menarik sendiri), dan jelaskan ke pewawancara kapan kamu mengutamakan latensi baca atau biaya tulis.
Presence service biasanya dipisah sebagai microservice sendiri yang hanya mengelola heartbeats, TTL, dan subscription perubahan status.
Bagian penting dalam wawancara adalah failure handling. Jelaskan strategi reconnection dengan exponential backoff, message deduplication menggunakan messageId idempoten, serta backpressure ketika klien lambat membaca.
Tambahkan juga metrik monitoring utama: p99 end-to-end latency, WebSocket connection count, broker lag, error rate, dan dropped message count.
Untuk latihan, biasakan diri menjelaskan desain seperti ini dalam 5–10 menit, lalu minta pewawancara hipotetis menguji bagian latensi, konsistensi, dan biaya agar kamu siap menghadapi variasi pertanyaan teknis berikutnya.
Latihan Wawancara Contoh Soal dan Ceklis Persiapan
Gunakan beberapa pola dari chat service tadi untuk latihan lain. Misalnya desain URL shortener: mulai dari asumsi volume write/read, estimasi kebutuhan storage, lalu gambar high-level design dengan API layer, application service, database utama, dan cache.
Sebutkan trade-off antara random key vs. hash, SQL vs. NoSQL, dan konsistensi read saat replication lag.
Latihan lain: news feed (pilih fan-out on write vs. fan-out on read), payment gateway (idempoten, exactly-once vs. at-least-once), file upload service (direct upload ke object storage, CDN), dan recommendation system (pemisahan offline batch dan online serving). Untuk tiap soal, latih urutan tetap: klarifikasi, asumsi, estimasi, desain, bottleneck, lalu trade-off.
Buat ceklis pra-wawancara: gambar cepat pada whiteboard, latihan back-of-the-envelope estimation, menutup tiap jawaban dengan 2–3 poin trade-off, kontrol waktu per bagian (misal 5 menit klarifikasi, 10 menit desain, 5 menit deep dive). Perhatikan juga bahasa: hindari terlalu teknis tanpa konteks, jelaskan dengan analogi singkat saat perlu.
Rencana latihan efektif: mock interview 30–60 menit dengan teman, rekam layar atau suara, lalu tonton ulang dan catat momen tidak jelas. Definisikan metrik perbaikan: skor 1–5 untuk clarity, kelengkapan architecture, kualitas alasan scalability, time management, dan komunikasi.
Lengkapi dengan sumber belajar: buku System Design Interview serta artikel teknis dari blog perusahaan teknologi besar.
Penutup
Setelah mengikuti struktur ini, pembaca mendapat kerangka kerja praktis untuk merancang dan mengkomunikasikan solusi sistem, memilih trade-off yang tepat, serta menghadapi pertanyaan teknis secara percaya diri.
Terapkan latihan studi kasus dan ceklis yang disarankan untuk mempercepat kesiapan wawancara serta menunjukkan kemampuan arsitektural yang terukur kepada pewawancara.
