Horizontal vs Vertical Scaling: Upgrade VPS, Bare Metal, atau Tambah Server

Gejalanya Biasanya Muncul Sebelum Istilah “Scaling” Dibicarakan

Di banyak bisnis, kebutuhan scaling tidak selalu dimulai dari capacity planning formal. Sering kali trigger-nya justru komplain user internal: ERP makin lambat, input transaksi tertunda, Finance harus menunggu data, atau Gudang tidak bisa melanjutkan proses karena aplikasi belum selesai memproses transaksi.

Beberapa sinyal yang cukup umum:

• aplikasi lancar pada jam sepi tetapi lambat ketika banyak user aktif;
• Admin, Finance, Gudang, Sales, atau divisi lain mulai berulang kali mengeluhkan aplikasi;
• proses input transaksi membutuhkan waktu lebih lama;
• request mulai timeout atau antrean worker/queue membesar;
• CPU atau RAM sering mendekati batas;
• restart server hanya memperbaiki kondisi sebentar;
• satu server down membuat seluruh aplikasi ikut berhenti.

Apa Itu Vertical Scaling dan Horizontal Scaling?

Referensi konsep autoscaling dan load balancing: Kubernetes Documentation dan NGINX Documentation.

Sebelum Memilih Vertical atau Horizontal Scaling, Cek Bottleneck-nya Dulu

Aplikasi lambat belum tentu berarti kapasitas server kurang. Bottleneck bisa berasal dari resource, database, query, storage I/O, cache, network, atau application process.

Capacity bottleneck baru cukup layak dipercaya ketika metric tinggi muncul konsisten bersama workload yang relevan, berkorelasi dengan penurunan performa yang dirasakan, dan penyebab lain yang masuk akal sudah diperiksa. Satu snapshot CPU 90% atau RAM hampir penuh belum cukup menjadi diagnosis.

Minimal cek:

• CPU utilization dan proses yang memakai CPU;
• RAM, swap, serta memory per process;
• storage I/O dan latency;
• database behavior, query, connection, dan cache;
• network dan external dependency;
• peak load dibanding average load;
• pola pertumbuhan workload.

Kapan Vertical Scaling Masih Masuk Akal?

1. Bottleneck memang berasal dari resource

CPU yang terus tinggi saat workload legitimate meningkat, atau memory pressure yang konsisten setelah process abnormal disingkirkan, dapat menjadi indikasi bahwa tambahan resource layak diuji.

2. Aplikasi masih lebih nyaman berjalan di satu instance

Aplikasi internal, ERP, POS, atau aplikasi vendor sering masih menyimpan session, file, job, atau konfigurasi tertentu pada satu server. Dalam kondisi seperti ini, vertical scaling biasanya lebih sederhana daripada langsung membangun multi-server architecture.

3. Operational simplicity masih bernilai

Satu server berarti deployment, troubleshooting, monitoring, dan recovery path lebih sederhana. Kalau resource lebih besar masih memberi headroom yang cukup, complexity tambahan belum tentu perlu dibayar.

Tanda Vertical Scaling Mulai Mentok

Ukuran server bukan indikator utamanya. Pertanyaan yang lebih berguna adalah: apakah upgrade berikutnya masih memberi hasil yang sebanding?

• upgrade terakhir memberi improvement yang semakin kecil;
• resource sudah besar tetapi response time tidak banyak berubah;
• workload tinggi sudah menjadi kondisi sehari-hari, bukan spike sesaat;
• biaya VPS terus naik tetapi dedicated resource mulai layak dibandingkan;
• satu server menjadi terlalu penting untuk seluruh proses bisnis.

Capacity Problem dan Availability Problem Itu Berbeda

Kapan Horizontal Scaling Mulai Relevan?

1. Request memang sudah bisa dibagi ke beberapa instance

Ini gate utamanya. Jika Server A, B, dan C dapat menangani request user tanpa session atau data menjadi tidak konsisten, aplikasi mulai lebih siap untuk horizontal scaling. Jika state masih terikat kuat ke satu instance, architecture perlu dibereskan lebih dulu.

2. Traffic atau workload memang membutuhkan kapasitas yang lebih mudah dibagi

Workload yang berubah signifikan antara jam normal dan peak dapat menjadi alasan menambah beberapa instance hanya jika workload memang bisa didistribusikan. Traffic spike sendiri bukan bukti bahwa horizontal scaling adalah pilihan yang tepat.

3. Uptime mulai sama pentingnya dengan performa

Ketika satu application server gagal dan seluruh user kehilangan akses, redundancy mulai menjadi kebutuhan tersendiri. Multi-instance application layer dapat membantu, tetapi database, storage, dan dependency lain juga perlu dinilai agar tidak tetap menjadi single point of failure.

4. Bagian aplikasi tumbuh dengan pola yang berbeda

Frontend, worker, reporting, API, dan queue tidak selalu tumbuh bersama. Horizontal scaling memberi ruang agar bagian tertentu berkembang sendiri-sendiri bila architecture memang memungkinkan.

Horizontal Scaling Bukan Sekadar “Tambah Server”

Menambah Server B di samping Server A belum otomatis membuat aplikasi horizontally scalable. Team juga perlu memikirkan request routing, session, shared storage, database connection, deployment consistency, health check, monitoring, dan failure handling.

Scalability dan Elasticity Bukan Hal yang Sama

Scalability adalah kemampuan sistem menambah kapasitas ketika workload berkembang. Elasticity adalah kemampuan kapasitas bertambah dan berkurang mengikuti perubahan demand, sering kali secara otomatis.

Contoh sederhana: mengubah server dari 4 vCPU menjadi 8 vCPU adalah scaling. Menambah replica ketika workload naik lalu menguranginya kembali ketika workload turun lebih dekat ke elasticity/autoscaling.

Kubernetes Horizontal Pod Autoscaler, misalnya, menyesuaikan jumlah replica berdasarkan metric seperti CPU, memory, atau custom metric. Lihat dokumentasi.

Tidak Semua Aplikasi Lambat Membutuhkan Scaling

Ada Pilihan Lain Selain VPS Lebih Besar atau Banyak Server: Dedicated Compute

Workload bisa tetap berjalan relatif terpusat, tetapi pindah dari virtual compute ke dedicated physical compute. Jalur ini mulai relevan ketika resource VPS sudah besar, workload konsisten tinggi, database/compute terus berat, atau economics dari VPS besar mulai kurang menarik.

Artinya, pilihan tidak harus mengikuti urutan VM → banyak VM. Pada kondisi tertentu jalurnya bisa VM → VM lebih besar, VM → dedicated compute, atau VM → beberapa instance.

Decision Matrix: Vertical, Horizontal, Dedicated, atau Jangan Scaling Dulu?

Cara Menjelaskan Keputusan Scaling ke Owner

PIC IT bisa saja sudah memahami masalahnya, tetapi approval budget sering datang dari orang yang tidak sehari-hari membaca metric server. Karena itu, technical finding perlu diterjemahkan menjadi dampak kerja dan alasan keputusan.

Forwardable Decision Memo untuk PIC IT

Format berikut dibuat agar bisa langsung disalin ke WhatsApp, email singkat, atau internal chat. Urutannya sengaja dimulai dari kondisi yang dirasakan user, lalu diterjemahkan ke pengecekan teknis, solusi, dan budget.

Pada MySQL/InnoDB, buffer pool menggunakan memory untuk cache data dan index; buffer pool terlalu kecil dapat menyebabkan churn, sementara terlalu besar juga dapat mendorong swapping. Karena itu memory harus dilihat bersama workload dan konfigurasi, bukan hanya dari angka “RAM penuh”. MySQL 8.4 Reference Manual.

Glosarium

Jadi, Kapan Vertical dan Kapan Horizontal Scaling?

Vertical scaling masuk akal ketika bottleneck memang berasal dari kapasitas satu server dan resource tambahan masih memberi improvement yang berarti.

Horizontal scaling mulai masuk akal ketika workload sudah bisa dibagi, kebutuhan availability meningkat, atau ketergantungan pada satu instance mulai menjadi batas yang tidak nyaman.

Dedicated compute layak dievaluasi ketika workload tetap cocok berjalan relatif terpusat tetapi kebutuhan resource sudah besar dan konsisten.

Dan kadang keputusan terbaik justru tidak scaling dulu. Jika bottleneck ada pada query, storage, cache, konfigurasi, atau application code, memperbaiki akar masalah lebih tepat daripada membeli resource baru.

Setelah perubahan dilakukan, ukur kembali gejala dan metric yang sama. Scaling baru dianggap membantu jika hasilnya benar-benar memperbaiki bottleneck yang ingin diselesaikan.

FAQ tentang Vertical dan Horizontal Scaling

Apakah RAM 90% berarti server harus di-upgrade?

Tidak otomatis. RAM tinggi adalah sinyal untuk diperiksa, bukan diagnosis. Lihat apakah memory pressure terjadi secara konsisten saat workload legitimate, apakah swap atau latency ikut meningkat, dan apakah kondisi tersebut benar-benar berkorelasi dengan penurunan performa aplikasi.

Mana yang lebih baik, vertical scaling atau horizontal scaling?

Tidak ada yang selalu lebih baik. Vertical scaling biasanya lebih sederhana ketika aplikasi masih cocok berjalan pada satu instance dan tambahan resource masih memberi headroom yang berarti. Horizontal scaling lebih relevan ketika workload memang dapat dibagi dan architecture siap menangani beberapa instance.

Kapan dedicated compute lebih masuk akal daripada terus memperbesar VPS?

Dedicated compute layak dievaluasi ketika kebutuhan resource sudah besar dan konsisten, dedicated resource memang dibutuhkan, atau biaya dan efisiensi VPS yang semakin besar mulai kurang rasional dibanding dedicated physical compute. Keputusan tetap perlu melihat workload, storage behavior, application architecture, kebutuhan operasional, dan budget.

Apakah horizontal scaling otomatis membuat aplikasi high availability?

Tidak. Menambah beberapa application server belum otomatis menghilangkan single point of failure. Database, storage, session, load balancer, network dependency, dan komponen lain tetap perlu dievaluasi agar tidak menjadi titik kegagalan tunggal.

Apakah aplikasi lambat selalu membutuhkan scaling?

Tidak. Query, database, storage I/O, cache, network, konfigurasi, atau application code bisa menjadi bottleneck utama. Jika akar masalah ada di layer tersebut, memperbaikinya biasanya lebih tepat daripada langsung menambah resource.

Daftar Pustaka

Referensi publik di bawah hanya memuat dokumentasi teknis yang digunakan untuk mendukung konsep dalam artikel.

1. Kubernetes Documentation. (n.d.). Horizontal Pod Autoscaling. Retrieved September 2, 2026, from https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/
2. NGINX. (n.d.). Using nginx as HTTP load balancer. Retrieved September 2, 2026, from https://nginx.org/en/docs/http/load_balancing.html
3. Oracle. (n.d.). MySQL 8.4 Reference Manual: How MySQL uses memory. Retrieved September 2, 2026, from https://dev.mysql.com/doc/refman/8.4/en/memory-use.html