Mulai dari satu server

Pertanyaan

Kapan satu mesin berhenti cukup, dan langkah paling murah berikutnya apa?

Setelah baca ini, kamu bisa milih satu langkah scaling pertama buat sebuah beban kerja, nyebut bukti yang mendukungnya, dan nyebut apa yang jadi lebih susah setelah langkah itu diambil.

Prasyarat dan contoh

Kamu sudah punya beban kerja, perkiraan kebutuhan, dan target yang bisa diukur (M01.02 sampai M01.04).

Sebuah aplikasi dengan 50.000 request per hari jalan di satu mesin: satu proses aplikasi, satu database, satu folder buat file. Tim baca artikel conference, terus mecahinnya jadi enam service. Hasilnya: enam deployment, enam dashboard, dan satu masalah lambat yang tetap sama karena penyebabnya query tanpa indeks.

Satu mesin yang bener ngalahin banyak mesin yang belum perlu. Scaling itu respons ke kendala yang udah kebukti, bukan proyek buat pamer di LinkedIn.

Mekanisme

Vertikal vs horizontal. Vertikal artinya mesinnya dibesarin: CPU, RAM, disk lebih kencang. Horizontal artinya mesinnya diperbanyak. Vertikal simpel dan nggak ngubah kode, tapi ada batas fisik dan biasanya berhenti di satu titik harga. Horizontal nambah kapasitas hampir linear, tapi nuntut aplikasi tanpa state lokal, routing traffic, dan koordinasi.

Susunan satu mesin yang jujur. Satu mesin bukan berarti tanpa struktur. Minimal:

klien → reverse proxy → proses aplikasi → database
                                     ↘ penyimpanan file

Reverse proxy ngurus TLS dan header. Proses aplikasi ngurus logika. Database nyimpen state. File storage nyimpen objek besar. Keempatnya boleh di mesin yang sama; yang penting batas tanggung jawabnya jelas, jadi nanti bisa dipisah tanpa nulis ulang logika.

Monolith vs service. Monolith artinya satu unit deployment. Itu bukan cacat. Batas modul di dalam monolith bisa tegas: modul A nggak baca tabel punya modul B, dan semuanya lewat interface fungsi. Misahin jadi service baru berguna kalau ada alasan operasional yang konkret: tim beda perlu rilis independen, komponen punya pola beban yang beda jauh, atau batas keamanan nuntut isolasi.

Urutan langkah yang biasanya masuk akal. Buat beban dominan baca:

1. Benerin query dan indeks. Ini sering nyelesaiin sebagian besar masalah.
2. Tambah cache di proses atau di depan aplikasi.
3. Pisahin database dari aplikasi biar masing-masing bisa dibesarin.
4. Tambah replika baca.
5. Baru pertimbangin sharding.

Buat beban dominan tulis, urutannya beda: batching, antrean, lalu partisi.

Biaya koordinasi. Tiap batas jaringan nambah mode gagal: timeout, retry, duplikasi, versi beda, dan observability terpisah. Satu mesin nggak punya masalah ini. Itu keunggulan nyata, bukan romantisme.

Saat rancangan ini gagal

• Mecah service buat masalah yang bukan soal batas service. Query lambat tetap lambat setelah dipindah ke service sendiri. Kamu cuma nambah jaringan di depannya.
• Horizontal tanpa stateless. Dua instance aplikasi dengan sesi di memori lokal bikin user "hilang" pas pindah instance. Solusinya bukan session affinity permanen, tapi mindahin state ke tempat bersama atau bikin state-nya bisa direkonstruksi.
• Anggap satu mesin tanpa batas. Satu mesin tetap punya batas: jumlah koneksi, file descriptor, IOPS disk, dan bandwidth jaringan. Tahu batasnya sebelum nyampe.
• Nunda pemisahan yang jelas dibutuhin. Kalau kebutuhan compliance misahin data pelanggan dari data analitik, itu alasan sah buat misahin dari awal. Simpel bukan berarti buta konteks.

Contoh tandingan: sebuah sistem nambah cache buat ngatasin latensi. Cache nurunin beban database, tapi bikin data yang baru ditulis kadang nggak kelihatan. Masalah kebenaran muncul karena langkah scaling diambil sebelum kendala sebenarnya dipahami.

Latihan

Katalog produk punya 1 juta request/hari, 95% baca. p95 latensi sekarang 1,2 detik. Database nunjukin 85% CPU kepakai buat satu query daftar produk yang nyisir tabel penuh. Aplikasi jalan di dua instance dengan sesi di memori.

Pilih langkah pertama dan jelasin.

Lihat pembahasan+

Langkah pertama: benerin query dan tambah indeks, bukan nambah instance atau mecah service.

Alasannya: buktinya satu query nyisir tabel penuh dan ngabisin 85% CPU database. Nambah instance aplikasi nggak ngurangin kerjaan yang sama. Mecah service cuma mindahin query yang sama ke jaringan lain. Indeks yang tepat nurunin kerjaan database langsung, dan efeknya bisa diukur di p95.

Langkah kedua yang masuk akal: keluarin sesi dari memori lokal, karena dua instance-nya udah ada. Ini soal kebenaran, bukan performa.

Yang belum perlu: cache terdistribusi dan sharding. Cache bisa nutupin query lambat, tapi setelah query-nya dibenerin mungkin udah nggak butuh. Sharding nambah kerumitan besar buat beban yang belum kebukti butuh.

Jawaban yang bagus nyebut bukti (CPU database, query plan), urutan langkah, dan satu hal yang sengaja ditunda.

Terkait

• M01.06 Kapan tidak perlu menambah infrastruktur nerusin kerangka keputusan ini.
• M02 Jaringan dan eksekusi request bahas reverse proxy dan load balancer.
• M06 Caching bahas cache setelah kendalanya kebukti.
• Lab L01 nunjukin gimana satu beban kerja bisa pindah pembatas pas parameternya diubah.

Catatan

• Asumsi: satu mesin jalanin aplikasi dan database; nggak ada kebutuhan compliance khusus.
• Yang nggak dibahas: milih cloud provider, container, orkestrasi, dan autoscaling.
• Urutan langkah itu heuristik, bukan aturan mutlak. Bukti pengukuran tetap yang nentuin.
• Terakhir ditinjau: 25 Oktober 2026.