Tentukan dulu masalahnya

Pertanyaan

Fitur apa yang beneran harus ada, dan bagian mana yang boleh gagal?

Kalau sudah selesai baca ini, kamu bisa nulis satu halaman ringkas berisi alur pengguna, kebutuhan fungsional, target yang ada angkanya, dan daftar hal yang sengaja nggak dikerjain.

Prasyarat dan contoh

Kamu sudah pernah bikin CRUD dan paham request HTTP. Nggak perlu pernah bikin sistem terdistribusi.

Pernah dengar permintaan kayak gini? "Bikin kayak bit.ly, tapi buat tim kita." Selesai bilang gitu, biasanya langsung muncul pertanyaan lain: tautannya berlaku berapa lama? perlu hitungan klik nggak? bisa dihapus? harus bisa dipakai dari aplikasi lain?

Kalau pertanyaan-pertanyaan itu nggak dijawab, tiap diskusi berikutnya jadi debat selera. Satu orang nambah fitur, satu orang nolak, dan nggak ada yang bisa bilang keputusan mana yang benar.

Nentuin batas masalah bukan berarti nolak fitur. Ini soal milih fitur mana yang menentukan bentuk sistem, dan mana yang bisa nyusul belakangan tanpa bongkar fondasi.

Mekanisme

Kerjain empat hal ini berurutan. Jangan langsung loncat ke "pakai Redis atau Postgres".

1. Alur pengguna. Tulis jalur terpendek dari niat sampai hasil. Buat URL shortener:

1. Orang tempel URL panjang.
2. Sistem kasih tautan pendek yang unik.
3. Orang lain buka tautan itu dan diarahkan ke URL asli.

Dari tiga langkah itu kelihatan dua operasi inti: simpan pemetaan, dan baca pemetaan. Fitur lain cuma tambahan di sekitarnya.

2. Kebutuhan fungsional. Tulis perilaku yang bisa dicek, bukan teknologi yang mau dipakai. "Pengguna bisa memperpendek URL" itu kebutuhan. "Sistem pakai Redis" itu pilihan implementasi, dan mungkin belum perlu.

3. Kebutuhan nonfungsional. Ubah kata sifat jadi angka. "Cepat" bukan kebutuhan. "Redirect selesai di bawah 100 ms di p95, untuk 200 request per detik saat ramai" baru bisa dipakai. Sekalian tentuin soal ketersediaan, durabilitas, konsistensi, dan batas biaya.

4. Yang nggak dikerjain. Tulis terang-terangan. Contoh: nggak ada analitik klik, nggak ada halaman admin, nggak ada custom link, nggak ada API publik, dan data nggak disimpan selamanya. Daftar ini yang nanti menyelamatkan desainmu: karena nggak ada analitik, jalur bacanya tetap sederhana dan murah.

Urutannya penting. Satu kebutuhan nonfungsional bisa membatalkan keputusan fungsional. Kalau kamu bilang "tautan harus masih bisa dibuka 10 tahun lagi", penyimpanan langsung jadi urusan fondasi, bukan detail belakangan.

Saat rancangan ini gagal

Biasanya bukan karena hitungannya salah, tapi karena batasnya nggak jujur.

• Non-goal yang ternyata wajib. Kamu tulis "tanpa analitik", minggu depan produk minta. Jalur tulis yang tadinya satu operasi sekarang butuh operasi kedua, dan skema yang kamu pilih nggak mendukung.
• Kebutuhan yang ditulis sebagai solusi. "Harus microservices" langsung ngunci arsitektur sebelum kamu tahu masalahnya apa. Kalau masalah aslinya query lambat, microservices nggak nolongin apa-apa.
• Target tanpa konsekuensi. Nulis "harus 99,99% tersedia" tanpa bilang apa yang terjadi kalau gagal bikin angka itu nggak bisa dipakai buat milih mekanisme apa pun.

Contoh tandingan: ada tim nulis "nggak pakai antrean" biar simpel. Begitu volume naik, pengiriman email memblokir request pengguna. Batasnya salah sejak awal karena ngabaikan kebutuhan respons cepat. Yang seharusnya ditulis: "respons ke pengguna nggak nunggu kerjaan pihak ketiga". Itu tetap mengizinkan antrean sebagai konsekuensi, bukan sebagai gaya-gayaan.

Latihan

Ambil kasus shortener internal: 40 engineer, dipakai buat dokumentasi, tautannya dishare di chat.

Tulis:

1. tiga alur pengguna,
2. empat kebutuhan fungsional yang bisa dicek,
3. tiga target dengan angka dan satuan,
4. dua hal yang sengaja nggak dikerjain.

Lihat pembahasan+

Contoh jawaban yang cukup:

Alur: (a) bikin tautan dari URL dokumen, (b) buka tautan lalu diarahkan, (c) cabut tautan yang salah.

Fungsional: bikin kode unik buat URL http/https; arahkan kode ke URL asli; tolak URL selain http/https; cabut tautan supaya nggak mengarah lagi.

Target: redirect p95 di bawah 100 ms pada 20 request per detik; tautan masih bisa dibuka setelah 2 tahun; kode unik nggak boleh bentrok sampai 1 juta tautan.

Nggak dikerjain: analitik klik, custom link, aplikasi mobile, API publik, retensi selamanya.

Perhatikan: tiap target punya satuan, dan tiap non-goal menghapus satu jalur desain. Jawaban yang bagus bisa dibaca engineer lain tanpa nanya "maksudnya gimana?".

Terkait

• Lanjut ke M01.02 Terjemahkan jadi angka.
• Lab L01 pakai tiga beban kerja berbeda buat nunjukin bahwa batas masalah yang sama bisa punya bottleneck yang beda.
• Rancangan D01 dan D02 belum tersedia.

Catatan

• Asumsi: tim kecil, nggak ada kebutuhan compliance khusus, dan URL yang dipendekkan bukan rahasia.
• Yang nggak dibahas: pilihan bahasa/framework, model data, dan keamanan tautan.
• Ini praktik umum nulis requirement, bukan kutipan dari satu sumber.
• Terakhir ditinjau: 25 Oktober 2026.