Minangka tech lead, kepiye nyiapake mundhake pangguna kaping sepuluh?

Question

IT Interview Practice · Accepted Answer

Minangka tech lead, aku dhisik bakal ngowahi **“pangguna sepuluh kaping luwih akeh” dadi perkiraan panggunaan, target layanan, lan rencana sing bisa ditindakake tim**. Cacah akun kadhaptar wae ora nuduhake pira request nalika paling rame.

Upamane bisnis ngrancang kampanye kanggo platform pesenan. Pitakonane apa pelanggan isih bisa ndeleng produk, tuku, lan nampa konfirmasi sajrone kampanye, kanthi wektu lan anggaran sing ana.

## 1. Owahi pertumbuhan dadi beban kerja

Takon marang tim produk kapan pangguna teka lan apa sing bakal ditindakake. Tambah alon sajrone setaun beda karo kampanye sing nggawa kabeh wong online bebarengan.

Minangka tuladha, 100.000 akun kadhaptar kanthi 1% aktif bebarengan tegese 1.000 pangguna serentak. Yen 5%, dadi 5.000. Iki asumsi tuladha, dudu rasio baku. Frekuensi request lan gaweyan saben request isih kudu dikira.

Dhaptar beban saka kampanye:

- Request ndeleng lan nggoleki, kalebu produk populer.
- Panulisan pesenan lan pembayaran nalika puncak.
- Panyimpenan sing tambah lan riwayat sing disimpen.
- Gaweyan latar mburi kayata notifikasi lan laporan.

Iki menehi beban sing bisa diuji, dudu prentah samar supaya server dikali sepuluh.

## 2. Sepakati apa sing kudu tetep apik

Temtokake wektu respons, tingkat error, lan rampunge alur penting sing bisa ditampa. Temtokake uga kesegaran data lan pangarep-arep pamulihan yen penting. Laporan telat bisa ditampa, nanging checkout gagal bisa ora.

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

Target nyambungake gaweyan teknis karo asil kanggo pelanggan. Iki mbantu mutusake apa perbaikan cukup lan penurunan layanan apa sing bisa ditampa nalika beban dhuwur.

## 3. Ukur wates saiki sadurunge milih owah-owahan

Gunakake pengamatan produksi lan uji beban sing makili nyata. Priksa query alon, koneksi database, CPU, memori, umur antrean, lan kuota layanan njaba. Lebokake trafik ora rata menyang barang populer, ora mung request acak.

Yen koneksi database dadi wates, nambah node aplikasi bisa nambah rebutan sumber daya. Yen kuota panyedhiya pembayaran dadi wates, aplikasi luwih cepet ora nambah kuota kasebut.

Uji cache kosong lan ilang siji instance, saliyane operasi normal. Kita butuh kapasitas pulih sajrone kampanye, ora mung cukup kanggo tes sing ideal.

## 4. Owahi temuan dadi gaweyan kanthi penanggung jawab

| Temuan | Tumindak sing bisa dipilih | Bukti sing dibutuhake |
| --- | --- | --- |
| Wacan larang bola-bali | Ndandani query utawa cache asil sing cocog | Gaweyan database mudhun kanthi kesegaran sing ditampa. |
| Tugas latar mburi saingan karo tuku | Matesi utawa misahake kapasitas | Checkout tetep sehat nalika beban latar mburi. |
| Kuota dependensi kurang | Ngatur kenaikan utawa ngontrol penerimaan | Kuota dikonfirmasi lan prilaku ing wates wis diuji. |
| Kapasitas kurang sawise perbaikan cilik | Evaluasi scaling utawa desain luwih gedhe | Manfaat diukur, rencana migrasi, lan biaya. |

Wenehana penanggung jawab, anggaran, dependensi, tenggat, lan tes penerimaan kanggo saben tumindak. Lebokake deployment, latihan operasional, lan persiapan on-call, ora mung implementasi.

Prioritas manut pengaruh marang pelanggan lan risiko pangiriman. Rewrite gedhe utawa sharding butuh alesan kabukten lan wektu cukup kanggo migrasi lan verifikasi.

## 5. Latih kampanye lan tambah trafik sethithik-sethithik

Rilis owah-owahan ing bagean sing bisa dikelola lan uji alur sing dikarepake bebarengan. Temtokake kapan nambah trafik, mandhegake kenaikan, utawa rollback. Owah-owahan format data bisa butuh pamulihan maju tinimbang rollback prasaja.

Siapake penurunan layanan sing dikontrol: tundha ekspor opsional, matesi gaweyan latar mburi, utawa nolak request keluwihan kanthi njaga operasi penting. Priksa manawa kontrol tenan nyuda beban lan pelanggan nampa asil sing cetha.

Yen target ora cocog wektu utawa anggaran, wenehana pilihan nyata marang produk: nambah pangguna bertahap, ngurangi fitur larang, utawa mbiayai hambatan sing diukur. Jlentrehake pengaruh pelanggan lan ketidakpastian saben pilihan.

**Elinga:** asumsi pertumbuhan → target layanan → wates diukur → rencana kanthi penanggung jawab → rollout sing dilatih. Tech lead menehi rencana kapasitas sing nyakup wong, dhuwit, lan pamulihan.

Temuan	Tumindak sing bisa dipilih	Bukti sing dibutuhake
Wacan larang bola-bali	Ndandani query utawa cache asil sing cocog	Gaweyan database mudhun kanthi kesegaran sing ditampa.
Tugas latar mburi saingan karo tuku	Matesi utawa misahake kapasitas	Checkout tetep sehat nalika beban latar mburi.
Kuota dependensi kurang	Ngatur kenaikan utawa ngontrol penerimaan	Kuota dikonfirmasi lan prilaku ing wates wis diuji.
Kapasitas kurang sawise perbaikan cilik	Evaluasi scaling utawa desain luwih gedhe	Manfaat diukur, rencana migrasi, lan biaya.

1. Owahi pertumbuhan dadi beban kerja

2. Sepakati apa sing kudu tetep apik

3. Ukur wates saiki sadurunge milih owah-owahan

4. Owahi temuan dadi gaweyan kanthi penanggung jawab

5. Latih kampanye lan tambah trafik sethithik-sethithik

Pitakon sing gegandhengan