Kapan tidak perlu menambah infrastruktur

Pertanyaan

Bukti apa yang cukup buat nambah infrastruktur baru, dan kapan jawaban terbaiknya justru "belum"?

Setelah baca ini, kamu bisa ngevaluasi usulan infrastruktur pakai empat kriteria dan ngambil keputusan yang bisa dibatalin tanpa ngerusak sistem.

Prasyarat dan contoh

Kamu sudah bisa njelasin beban kerja, ngitung kebutuhan, nentuin target, dan milih langkah scaling pertama (M01.02 sampai M01.05).

Dua tim punya masalah yang kelihatannya sama: halaman lambat. Tim pertama nambah cache terdistribusi. Tim kedua nemu satu query yang nggak pakai indeks. Tim pertama sekarang punya komponen baru buat dioperasikan, plus bug data basi. Tim kedua nyelesaiin masalahnya dengan satu perubahan kecil. Bedanya bukan kemampuan teknis, tapi urutan bukti.

Mekanisme

Pakai empat pertanyaan ini berurutan. Kalau ada satu yang belum kejawab, keputusannya belum matang.

1. Kendala mana yang terukur? Bukan dugaan, bukan "kayaknya". Sebut metriknya, nilainya, dan kapan diamatinya. "p95 naik dari 200 ms ke 1,2 detik sejak Selasa" itu bukti. "Rasanya lambat" bukan.

2. Komponen baru ini beneran ngilangin kendalanya? Cache ngilangin pembacaan berulang. Cache nggak benerin query yang salah atau data yang nggak konsisten. Antrean mindahin kerjaan dari jalur request. Antrean nggak bikin kerjaan itu lebih cepat.

3. Total biayanya berapa? Biayanya bukan cuma mesin. Ada komponen baru buat dipantau, mode gagal baru, prosedur pemulihan, pengetahuan tim, dan waktu yang jadi nggak kepakai buat benerin hal lain. Infrastruktur yang nggak dipahami lebih bahaya daripada nggak ada.

4. Gampang dibatalin nggak? Pilihan yang gampang dibatalin boleh diambil dengan bukti lebih sedikit. Nambah indeks gampang dibatalin. Milih model data buat data yang nggak bisa dimigrasi tanpa downtime nggak gampang. Buat keputusan yang susah dibatalin, buktinya harus lebih kuat.

Biaya peluang. Tiap komponen yang ditambah bersaing sama perbaikan yang lebih murah. Sering kali nilai paling gede bukan dari komponen baru, tapi dari ngapus kerjaan yang nggak perlu: query berlebih, payload kegedean, atau endpoint yang nggak dipakai.

Tulis keputusannya. Catat: kendala, bukti, alternatif yang ditolak, konsekuensi, dan kondisi yang bakal ngebatalin keputusan. Ini bikin "belum" jadi keputusan yang sah, bukan kelalaian.

Saat rancangan ini gagal

• Infrastruktur buat nutupin gejala. Nambah antrean buat nyembunyiin query lambat bikin latensi user turun sementara, lalu balik lagi pas antreannya numpuk. Gejalanya pindah, penyebabnya tetap.
• Cache buat masalah kebenaran. Cache nggak benerin data yang salah. Dia malah nyimpen lebih lama dan nyebarin ke lebih banyak user.
• Keputusan karena tren. Milih teknologi karena populer berarti nggak jawab pertanyaan paling penting: dia ngilangin kendala kita nggak, dan siapa yang bakal ngoperasiin?
• "Belum" tanpa syarat. Nunda tanpa nulis bukti apa yang bakal ngubah keputusan bikin penundaan berulang tanpa arah. Tulis: "kami nambah cache kalau hit rate pembacaan yang sama lewat X dan database tetap di atas Y%."

Contoh tandingan: ada tim nolak semua infrastruktur tambahan. Pas traffic naik 10×, satu mesin kehabisan koneksi dan nggak ada jalur cache yang siap. Simpel bukan berarti pasif. Batas mesin harus diketahui, dipantau, dan rencana langkah berikutnya harus ada sebelum dibutuhin.

Latihan

Buat tiap usulan, putusin ambil sekarang, tunda dengan syarat, atau tolak, lalu sebut alasannya.

1. p95 daftar produk 1,4 detik; query plan-nya nyisir tabel penuh. Usulan: cache terdistribusi.
2. Hit rate cache 3%; biaya operasional cache lebih besar dari penghematannya. Usulan: pertahankan cache.
3. Traffic puncak 1,7 request/detik; kapasitas aplikasi 200 request/detik. Usulan: sharding database.
4. Satu query pembayaran ngunci baris selama 400 ms dan bikin timeout. Usulan: pisahin service pembayaran.

Lihat pembahasan+

1. Tunda. Benerin query dan indeks dulu. Cache bakal nutupin masalahnya dan nambah risiko data basi. Syarat buat ambil cache: setelah query dibenerin, pembacaan berulang yang sama masih dominan dan database tetap di atas ambang yang kamu tentuin.
2. Tolak. Cache dengan hit rate 3% hampir nggak ngurangin kerjaan, tapi nambah komponen, mode gagal, dan biaya. Hapus kalau nggak ada alasan lain.
3. Tolak. Utilisasi aplikasi di bawah 1%. Sharding nambah kerumitan besar buat kendala yang nggak ada. Ukur dulu komponen yang beneran deket batas.
4. Tunda sambil benerin. 400 ms dengan lock itu tanda masalah transaksi atau query, bukan masalah batas service. Benerin cakupan lock dan durasi transaksi dulu. Misahin service nambah jaringan dan konsistensi terdistribusi tanpa ngilangin lock yang sama.

Polanya: cari penyebab termurah dulu, dan tulis kondisi yang bakal ngubah keputusan. "Tunda" tanpa syarat bukan keputusan.

Terkait

• Lab L01 itu tempat nguji intuisi ini. Ubah satu parameter dan lihat pembatasnya pindah. Skenario "peluncuran viral" dan "arsip tulis berat" punya pembatas beda walaupun strukturnya sama.
• M06 Caching tanpa ngorbankan kebenaran bahas cache setelah kendalanya kebukti.
• M09 Mesin penyimpanan bahas biaya nyata penyimpanan.
• Rancangan D01 dan D02 belum tersedia. Dua-duanya bakal pakai shortener yang sama di dua tingkat skala.

Catatan

• Asumsi: tim kecil dengan kapasitas operasional terbatas.
• Kerangka "pintu dua arah" itu metafora keputusan yang umum dipakai, bukan kutipan dari satu sumber.
• Yang nggak dibahas: perhitungan biaya cloud secara rinci dan proses pengadaan.
• Terakhir ditinjau: 25 Oktober 2026.