Bagaimana tech lead merencanakan pertumbuhan pengguna sepuluh kali?

Question

IT Interview Practice · Accepted Answer

Sebagai tech lead, saya akan terlebih dahulu menerjemahkan **“pengguna bertambah sepuluh kali” menjadi perkiraan penggunaan, target layanan, dan rencana yang mampu dijalankan tim**. Jumlah akun terdaftar saja tidak menunjukkan banyaknya request pada saat tersibuk.

Misalnya bisnis merencanakan kampanye untuk platform pemesanan. Pertanyaannya adalah apakah pelanggan tetap dapat melihat produk, membeli, dan menerima konfirmasi selama kampanye, dengan waktu dan anggaran yang tersedia.

## 1. Terjemahkan pertumbuhan menjadi beban kerja

Tanyakan kepada tim produk kapan pengguna akan datang dan tindakan apa yang akan dilakukan. Pertumbuhan bertahap selama setahun berbeda dari kampanye yang membuat semua orang masuk bersamaan.

Sebagai ilustrasi, 100.000 akun terdaftar dengan 1% aktif bersamaan berarti 1.000 pengguna serentak. Jika 5% aktif, jumlahnya 5.000. Ini contoh asumsi, bukan rasio baku. Frekuensi request dan pekerjaan per request tetap perlu diperkirakan.

Daftarkan beban yang ditimbulkan kampanye:

- Request penelusuran dan pencarian, termasuk produk populer.
- Penulisan pesanan dan pembayaran pada waktu puncak.
- Pertumbuhan penyimpanan dan riwayat yang dipertahankan.
- Pekerjaan latar belakang seperti notifikasi dan laporan.

Dengan demikian, ada beban nyata yang dapat diuji, bukan instruksi samar untuk mengalikan jumlah server dengan sepuluh.

## 2. Sepakati kualitas yang harus dipertahankan

Tentukan waktu respons, tingkat error, dan keberhasilan penyelesaian yang dapat diterima untuk alur penting. Tentukan juga kesegaran data dan harapan pemulihan ketika relevan. Laporan yang terlambat mungkin dapat diterima, sedangkan checkout gagal tidak.

```text
[Campaign assumptions] -> [Expected workload] -> [Service targets]
                                                   |
                                            [Acceptance tests]
```

Target menghubungkan pekerjaan teknis dengan hasil bagi pelanggan. Target membantu menentukan apakah perbaikan sudah cukup dan penurunan layanan apa yang masih dapat diterima saat beban tinggi.

## 3. Ukur batas saat ini sebelum memilih perubahan

Gunakan pengamatan produksi dan uji beban yang mewakili penggunaan sebenarnya. Periksa kueri lambat, koneksi database, CPU, memori, usia pekerjaan dalam antrean, dan kuota layanan eksternal. Sertakan trafik yang tidak merata ke produk populer, bukan hanya request acak.

Jika batasnya adalah koneksi database, penambahan node aplikasi justru dapat meningkatkan perebutan sumber daya. Jika batasnya kuota penyedia pembayaran, aplikasi yang lebih cepat tidak menaikkan kuota tersebut.

Uji cache kosong dan hilangnya satu instance, selain operasi normal. Kapasitas harus cukup untuk pulih selama kampanye, bukan hanya cukup dalam pengujian ideal.

## 4. Ubah temuan menjadi pekerjaan dengan penanggung jawab

| Temuan | Tindakan yang dapat dipertimbangkan | Bukti yang dibutuhkan |
| --- | --- | --- |
| Pembacaan mahal yang berulang | Perbaiki kueri atau cache hasil yang sesuai | Beban database turun dengan kesegaran data yang dapat diterima. |
| Tugas latar belakang bersaing dengan pembelian | Batasi atau pisahkan kapasitasnya | Checkout tetap sehat ketika tugas latar belakang berjalan. |
| Kuota dependensi tidak cukup | Ajukan kenaikan atau kendalikan penerimaan request | Kuota sudah dikonfirmasi dan perilaku pada batasnya sudah diuji. |
| Kapasitas tetap kurang setelah perbaikan kecil | Evaluasi penambahan kapasitas atau perubahan desain lebih besar | Manfaat terukur, rencana migrasi, dan biaya. |

Berikan penanggung jawab, anggaran, dependensi, tenggat, dan uji penerimaan untuk setiap tindakan. Sertakan deployment, pelatihan operasional, dan persiapan petugas siaga, bukan hanya implementasi.

Prioritaskan berdasarkan dampak pelanggan dan risiko penyelesaian. Penulisan ulang besar atau proyek sharding membutuhkan alasan yang terbukti serta waktu yang cukup untuk migrasi dan verifikasi.

## 5. Latih skenario kampanye dan tingkatkan trafik bertahap

Rilis perubahan dalam bagian yang dapat dikelola dan uji seluruh alur yang diharapkan bersama-sama. Tentukan kapan trafik ditambah, penambahan dihentikan, atau perubahan dibatalkan. Perubahan format data mungkin memerlukan perbaikan lanjutan, bukan rollback sederhana.

Siapkan penurunan layanan yang terkendali: tunda ekspor opsional, batasi pekerjaan latar belakang, atau tolak request berlebih sambil mempertahankan operasi penting. Pastikan kontrol tersebut benar-benar menurunkan beban dan pelanggan menerima hasil yang jelas.

Jika target tidak sesuai tenggat atau anggaran, sampaikan pilihan konkret kepada tim produk: datangkan pengguna bertahap, kurangi fitur mahal, atau danai penanganan hambatan yang terukur. Jelaskan dampak pelanggan dan ketidakpastian setiap pilihan.

**Ingat:** asumsi pertumbuhan → target layanan → batas terukur → rencana dengan penanggung jawab → peluncuran yang sudah dilatih. Tech lead menghasilkan rencana kapasitas yang mencakup orang, biaya, dan pemulihan.

Temuan	Tindakan yang dapat dipertimbangkan	Bukti yang dibutuhkan
Pembacaan mahal yang berulang	Perbaiki kueri atau cache hasil yang sesuai	Beban database turun dengan kesegaran data yang dapat diterima.
Tugas latar belakang bersaing dengan pembelian	Batasi atau pisahkan kapasitasnya	Checkout tetap sehat ketika tugas latar belakang berjalan.
Kuota dependensi tidak cukup	Ajukan kenaikan atau kendalikan penerimaan request	Kuota sudah dikonfirmasi dan perilaku pada batasnya sudah diuji.
Kapasitas tetap kurang setelah perbaikan kecil	Evaluasi penambahan kapasitas atau perubahan desain lebih besar	Manfaat terukur, rencana migrasi, dan biaya.

1. Terjemahkan pertumbuhan menjadi beban kerja

2. Sepakati kualitas yang harus dipertahankan

3. Ukur batas saat ini sebelum memilih perubahan

4. Ubah temuan menjadi pekerjaan dengan penanggung jawab

5. Latih skenario kampanye dan tingkatkan trafik bertahap

Pertanyaan terkait