Apa itu system design; functional vs non-functional requirement
Apa yang dinilai di ronde system design, cara menulis requirement dengan angka, dan prinsip inti track ini
1. Apa yang sebenarnya dinilai
Soal system design berbentuk terbuka: "rancang URL shortener", "rancang aplikasi chat". Tidak ada satu jawaban benar. Yang dinilai adalah cara Anda memilih: requirement apa yang Anda tanyakan, angka apa yang Anda hitung, dan alasan di balik setiap komponen.
Jeff Dean (Google) merumuskannya begini: dari satu definisi masalah, "best" bisa berarti "simplest, highest performance, easiest to extend, etc.", dan keterampilan pentingnya adalah "ability to estimate performance of a system design – without actually having to build it!" [1] Perhatikan urutannya: simplest disebut pertama.
2. Functional vs non-functional requirement
Requirement adalah titik awal setiap soal. Pisahkan dua jenis:
| Functional | Non-functional | |
|---|---|---|
| Pertanyaan | Sistem melakukan apa? | Sistem harus seberapa baik? |
| Contoh (URL shortener) | Membuat link pendek; redirect ke URL asli; link bisa kedaluwarsa | Redirect cepat; jarang down; berapa user; boleh telat konsisten? |
| Bentuk yang baik | Kalimat kerja: "user bisa …" | Angka: latency, availability, jumlah user, ukuran data |
Non-functional requirement tanpa angka tidak bisa dipakai untuk memilih desain. "Harus cepat" tidak memberi tahu apa-apa; "p99 redirect di bawah 100 ms" (99% request selesai di bawah 100 ms, dibahas di lesson 0003) langsung menentukan apakah perlu cache. Google SRE Book menyebut ukuran seperti ini SLI (service level indicator), "a carefully defined quantitative measure" dari layanan, dengan latency sebagai SLI utama di kebanyakan layanan. [2]
Availability juga ditulis sebagai angka. Setiap "sembilan" tambahan memangkas jatah downtime 10 kali lipat: [3]
| Availability | Downtime per tahun | per bulan | per hari |
|---|---|---|---|
| 99% | 3,65 hari | 7,2 jam | 14,4 menit |
| 99,9% | 8,76 jam | 43,2 menit | 1,44 menit |
| 99,99% | 52,6 menit | 4,32 menit | 8,64 detik |
Kenapa penting: 99,99% berarti sistem harus pulih sendiri dalam hitungan detik, tanpa menunggu orang bangun tengah malam. Itu mahal. Jadi tanyakan dulu ke interviewer berapa yang dibutuhkan, jangan langsung menjanjikan angka tertinggi.
3. Prinsip inti: ukur dulu, mulai dari yang paling murah
Seluruh track ini memegang satu prinsip: ukur dulu, lalu mulai dari perubahan yang paling murah dan paling kecil risikonya. Arsitektur baru adalah jalan terakhir. Di interview, prinsip ini berbentuk desain v1: desain paling sederhana yang memenuhi angka requirement.
Kenapa tidak langsung memasang semuanya? Setiap komponen tambahan punya biaya tetap, terpakai atau tidak: satu lagi yang harus di-deploy, dipantau, dan diperbaiki saat rusak. Memecah aplikasi menjadi banyak service (microservices: aplikasi dipecah menjadi service kecil yang di-deploy terpisah dan saling memanggil lewat jaringan) mengubah pemanggilan fungsi biasa menjadi panggilan jaringan yang lebih lambat dan bisa gagal. Biaya itu layak dibayar kalau angka menuntutnya, bukan sebelumnya. Urutannya selalu: ukur dulu, perbaiki yang termurah, dan pecah arsitektur sebagai jalan terakhir.
| Soal: aplikasi internal, 1.000 user | Terdengar over-engineer | Terdengar terukur |
|---|---|---|
| Arsitektur | "Saya pakai microservices, Kafka, dan Kubernetes." | "Satu app server dan satu database cukup. Ini hitungannya." |
| Kapan berubah | Tidak disebut; semuanya dipasang dari awal. | "Kalau p99 naik melewati target, saya cek query dan index dulu, baru cache." |
Kolom kanan bukan berarti tidak tahu komponen canggih. Kolom kanan tahu kapan komponen itu dibutuhkan. Hitungan "1.000 user cukup satu server" ada di lesson 0004, dan urutan lengkap perubahan dari yang termurah ada di lesson 0025 (tangga skala). Setiap lesson komponen sesudah ini punya bagian "Kapan tidak perlu".
Latihan 1 — Functional atau non-functional?
Latihan 2 — Desain v1 dan prinsip inti
Latihan lisan — Jawab lisan
Pasang timer, jawab dengan suara keras seolah sedang interview, baru buka jawaban contoh. Soal ini juga ada di bank soal dan bisa ditarik review 0012.
"Interviewer: rancang aplikasi absensi untuk kantor dengan 1.000 karyawan. Apa yang Anda lakukan di dua menit pertama, dan kenapa Anda tidak langsung memilih microservices?" (60 detik)
Bandingkan dengan jawaban contoh dan checklist-nya
"Saya mulai dari requirement. Functional: karyawan check-in dan check-out, HR melihat rekap. Non-functional saya minta dalam angka: berapa user aktif, kapan puncaknya (mungkin jam 8 pagi), berapa latency yang bisa diterima, dan availability yang dibutuhkan, misalnya 99,9% berarti boleh down sekitar 43 menit sebulan. Lalu saya hitung kasar: 1.000 karyawan dengan beberapa request per hari itu sangat kecil, jadi desain v1 saya satu app server dan satu database. Microservices menambah biaya mengelola banyak service: deploy, monitoring, dan panggilan jaringan antar-service yang bisa gagal. Kalau nanti metrik menunjukkan bottleneck, saya mulai dari perubahan termurah seperti index atau cache."
Checklist: apakah Anda menyebut…
- mulai dari requirement sebelum menggambar komponen?
- minimal dua functional requirement dalam bentuk "user bisa …"?
- non-functional requirement sebagai angka (user, puncak, latency, atau availability)?
- hitungan kasar yang menunjukkan bebannya kecil?
- desain v1: satu app server dan satu database?
- alasan menolak microservices (biaya mengelola banyak service) dan langkah termurah kalau nanti lambat?
Lulus kalau minimal 4 dari 6.
Berikutnya, lesson 0002: sebelum memasang komponen apa pun, apa saja yang terjadi saat browser mengirim satu request ke server?
Ada yang belum jelas? Tanyakan ke agent. Agent adalah guru Anda di track ini.
Istilah: GLOSSARY.md (bagian "Prinsip dan kerangka", "Fondasi") · Sumber: RESOURCES.md
Sumber: [1] Jeff Dean, LADIS 2009 keynote (slide "Designing Efficient Systems") · [2] Google SRE Book, bab 4 Service Level Objectives · [3] Google SRE Book, Availability Table