Kenali saat infrastruktur tambahan belum diperlukan

Pertanyaan

Bukti apa yang cukup untuk membenarkan menambah infrastruktur baru, dan kapan jawaban terbaiknya adalah "belum"?

Hasil yang bisa diamati: kamu bisa mengevaluasi usulan infrastruktur memakai empat kriteria dan menghasilkan keputusan yang bisa dibatalkan tanpa merusak sistem.

Prasyarat dan contoh

Kamu sudah bisa menjelaskan beban kerja, menghitung kebutuhan, menetapkan sasaran, dan memilih langkah penskalaan pertama (M01.02–M01.05).

Dua tim punya masalah yang terlihat sama: halaman lambat. Tim pertama menambahkan cache terdistribusi. Tim kedua menemukan satu query yang tidak memakai indeks. Tim pertama sekarang punya komponen baru untuk dioperasikan, plus bug data usang. Tim kedua menyelesaikan masalahnya dalam satu perubahan kecil. Bedanya bukan kemampuan teknis, melainkan urutan bukti.

Mekanisme

Gunakan empat pertanyaan berikut, secara berurutan. Jika salah satu tidak terjawab, keputusannya belum matang.

1. Kendala mana yang terukur? Bukan dugaan, bukan "kayaknya". Sebut metrik, nilainya, dan waktu pengamatan. "p95 naik dari 200 ms ke 1,2 detik sejak Selasa" adalah bukti. "Terasa lambat" bukan.

2. Apakah komponen baru benar-benar menghilangkan kendala itu? Cache menghilangkan pembacaan berulang. Cache tidak memperbaiki query yang salah atau data yang tidak konsisten. Antrean memindahkan pekerjaan dari jalur request. Antrean tidak membuat pekerjaan itu lebih cepat.

3. Berapa biaya totalnya? Biaya mencakup mesin, tetapi juga: komponen baru untuk dipantau, mode kegagalan baru, prosedur pemulihan, pengetahuan tim, dan waktu yang tidak dipakai untuk memperbaiki hal lain. Infrastruktur yang tidak dipahami lebih berbahaya daripada tidak ada.

4. Seberapa mudah dibatalkan? Pilihan yang mudah dibatalkan boleh diambil dengan bukti lebih sedikit. Menambah indeks mudah dibatalkan. Memilih model data untuk data yang tidak bisa dimigrasi tanpa downtime tidak mudah dibatalkan. Untuk keputusan sulit dibatalkan, bukti harus lebih kuat.

Biaya peluang. Setiap komponen yang ditambahkan bersaing dengan perbaikan yang lebih murah. Sering kali nilai tertinggi bukan dari komponen baru, melainkan dari menghapus pekerjaan yang tidak perlu: query berlebih, payload besar, atau endpoint yang tidak dipakai.

Menuliskan keputusan. Catat: kendala, bukti, alternatif yang ditolak, konsekuensi, dan kondisi yang akan membatalkan keputusan. Ini membuat "belum" menjadi keputusan yang sah, bukan kelalaian.

Saat rancangan ini gagal

• Infrastruktur sebagai penutup gejala. Menambahkan antrean untuk menyembunyikan query lambat membuat latensi pengguna turun sementara, lalu kembali saat antrean menumpuk. Gejalanya berpindah, penyebabnya tetap.
• Cache untuk masalah kebenaran. Cache tidak memperbaiki data yang salah; ia menyimpannya lebih lama dan menyebarkannya ke lebih banyak pengguna.
• Keputusan berdasarkan tren. Memilih teknologi karena populer mengabaikan pertanyaan yang paling penting: apakah ia menghilangkan kendala kita, dan siapa yang akan mengoperasikannya?
• "Belum" tanpa syarat. Menunda tanpa menuliskan bukti apa yang akan mengubah keputusan membuat penundaan berulang tanpa arah. Tulis: "kami akan menambahkan cache jika hit rate pembacaan yang sama melewati X dan basis data tetap di atas Y%."

Contoh tandingan: sebuah tim menolak semua infrastruktur tambahan. Saat trafik naik 10×, satu mesin kehabisan koneksi dan tidak ada jalur cache yang siap. Sederhana bukan berarti pasif; batas mesin harus diketahui dan dipantau, dan rencana langkah berikutnya harus ada sebelum dibutuhkan.

Latihan

Untuk setiap usulan, putuskan ambil sekarang, tunda dengan syarat, atau tolak, lalu sebutkan alasannya.

1. p95 daftar produk 1,4 detik; rencana query memindai tabel penuh. Usulan: cache terdistribusi.
2. Hit rate cache 3%; biaya operasional cache lebih besar dari penghematan. Usulan: pertahankan cache.
3. Trafik puncak 1,7 request/detik; kapasitas aplikasi 200 request/detik. Usulan: sharding basis data.
4. Satu query pembayaran mengunci baris selama 400 ms dan menyebabkan timeout. Usulan: pisahkan layanan pembayaran.

Lihat pembahasan+

1. Tunda. Perbaiki query dan indeks lebih dulu. Cache akan menutupi masalah dan menambah risiko data usang. Syarat untuk mengambil cache: setelah query diperbaiki, pembacaan berulang yang sama masih mendominasi dan basis data tetap di atas ambang yang kamu tetapkan.
2. Tolak. Cache dengan hit rate 3% hampir tidak mengurangi pekerjaan, tetapi menambah komponen, mode kegagalan, dan biaya. Hapus jika tidak ada alasan lain.
3. Tolak. Utilisasi aplikasi di bawah 1%. Sharding menambah kompleksitas besar untuk kendala yang tidak ada. Ukur dulu komponen yang benar-benar dekat batas.
4. Tunda sambil memperbaiki. 400 ms dengan lock menunjukkan masalah transaksi atau query, bukan masalah batas layanan. Perbaiki cakupan lock dan durasi transaksi lebih dulu. Memisahkan layanan menambah jaringan dan konsistensi terdistribusi tanpa menghilangkan lock yang sama.

Pola jawabannya: cari penyebab termurah terlebih dahulu, dan nyatakan kondisi yang akan mengubah keputusan. "Tunda" tanpa syarat bukan keputusan.

Terkait

• Lab L01 adalah tempat menguji intuisi ini: ubah satu parameter dan lihat pembatas berpindah. Skenario "peluncuran viral" dan "arsip tulis berat" punya pembatas berbeda meski strukturnya sama.
• M06 Caching tanpa mengorbankan kebenaran membahas cache setelah kendalanya terbukti.
• M09 Mesin penyimpanan membahas biaya nyata penyimpanan.
• Rancangan D01 dan D02 belum tersedia; keduanya akan memakai shortener yang sama pada dua tingkat skala.

Catatan

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