Elasticity vs Scalability #

Elasticity dan scalability adalah dua istilah yang sering digunakan bergantian, padahal keduanya merujuk pada konsep yang berbeda. Menggunakannya secara salah bukan hanya masalah semantik — ia bisa mengarahkan keputusan arsitektur ke arah yang keliru. Memahami perbedaannya dengan tepat membantu kamu merancang sistem yang efisien secara biaya sekaligus mampu menangani beban yang berubah-ubah.

Definisi Masing-Masing #

Mari mulai dengan definisi yang presisi sebelum membandingkan keduanya.

Scalability adalah kemampuan sistem untuk menangani peningkatan beban kerja dengan menambahkan sumber daya. Ini adalah sifat kapasitas — sistem yang scalable bisa ditingkatkan kapasitasnya untuk mengakomodasi pertumbuhan.

Elasticity adalah kemampuan sistem untuk secara otomatis menyesuaikan sumber daya yang dialokasikan sesuai dengan beban aktual saat itu — naik ketika beban tinggi, turun ketika beban rendah. Ini adalah sifat adaptasi otomatis terhadap permintaan yang berubah-ubah.

Analogi Sederhana:

  Scalability = Kapasitas jalan tol
      Jalan tol 2 jalur bisa "di-scale" menjadi 4 jalur
      dengan menambah jalur baru (butuh perencanaan dan waktu)

  Elasticity = Sistem buka-tutup jalur darurat
      Jalur darurat dibuka saat macet pagi hari,
      ditutup saat lalu lintas sepi
      → Otomatis, responsif terhadap kondisi real-time

Scalability — Tumbuh Seiring Kebutuhan #

Scalability bicara tentang kemampuan sistem untuk tumbuh. Ada dua bentuk utama: vertical dan horizontal.

Vertical Scaling (Scale Up) #

Menambah kapasitas dengan meningkatkan spesifikasi satu node — lebih banyak CPU, RAM, atau storage pada server yang sudah ada.

Sebelum Scale Up:
  Server: 4 vCPU, 8 GB RAM
  Beban mulai melebihi kapasitas

Setelah Scale Up:
  Server: 16 vCPU, 64 GB RAM
  
  Keuntungan:
  ✓ Sederhana — tidak ada perubahan arsitektur
  ✓ Cocok untuk aplikasi yang sulit didistribusikan (legacy DB)

  Keterbatasan:
  ✗ Ada batas maksimum hardware
  ✗ Downtime sering dibutuhkan untuk resize
  ✗ Single point of failure tetap ada
  ✗ Biaya tidak linear — server besar sangat mahal

Horizontal Scaling (Scale Out) #

Menambah kapasitas dengan menambah lebih banyak node yang bekerja bersama.

Sebelum Scale Out:
  [Server A] ← semua trafik

Setelah Scale Out:
  [Load Balancer]
      ├── [Server A]
      ├── [Server B]
      └── [Server C]

  Keuntungan:
  ✓ Tidak ada batas teoritis — tambah node sesuai kebutuhan
  ✓ Tidak ada single point of failure
  ✓ Biaya lebih linear
  ✓ Cocok untuk cloud-native architecture

  Keterbatasan:
  ✗ Aplikasi harus dirancang untuk distributed (stateless)
  ✗ Lebih kompleks untuk dikelola

Elasticity — Adaptasi Otomatis #

Elasticity adalah lapisan di atas scalability. Sistem yang elastic bisa scale out dan scale in secara otomatis berdasarkan kondisi real-time. Kata kunci di sini adalah: otomatis dan dua arah.

Pola Beban Kerja yang Tidak Elastis vs Elastis:

  Tanpa Elasticity (kapasitas tetap):
  
  Kapasitas: ████████████████████ (tetap di level puncak)
  Beban:     ██░░░░████░░░░██████ (berubah-ubah)
  
  Saat beban rendah → banyak resource terbuang (bayar tapi tidak dipakai)
  Saat beban puncak → masih aman karena selalu over-provisioned
  Biaya: tinggi dan konstan

  Dengan Elasticity (kapasitas mengikuti beban):
  
  Kapasitas: ██░░░░████░░░░██████ (mengikuti beban)
  Beban:     ██░░░░████░░░░██████
  
  Resource selalu sesuai dengan kebutuhan aktual
  Biaya: proporsional dengan beban aktual

Elasticity adalah yang membuat model pay-as-you-go cloud benar-benar efisien. Tanpa elasticity, kamu tetap membayar untuk kapasitas yang tidak digunakan.

Hubungan Antara Keduanya #

Elasticity membutuhkan scalability sebagai fondasi — sistem tidak bisa elastic jika tidak bisa di-scale. Tapi tidak semua sistem yang scalable itu elastic.

Matriks Scalability vs Elasticity:

  Scalable + Elastic:
    → Cloud-native application dengan auto-scaling
    → Ideal untuk beban yang fluktuatif
    → Contoh: web app e-commerce yang scale saat flash sale

  Scalable, Tidak Elastic:
    → Sistem yang bisa ditambah kapasitasnya tapi secara manual
    → Cocok untuk pertumbuhan yang predictable dan lambat
    → Contoh: database yang di-scale up saat data tumbuh

  Tidak Scalable, Tidak Elastic:
    → Sistem monolitik dengan resource tetap
    → Masalah ketika beban melampaui kapasitas
    → Umumnya: legacy application on-premise

Implikasi untuk Desain Sistem #

Untuk sistem bisa elastic, ada prasyarat arsitektur yang harus dipenuhi.

Prasyarat Sistem yang Elastic:

  1. Stateless application
     ✓ Tidak ada session state yang disimpan di memori server
     ✓ State disimpan di external store (Redis, database)
     → Jika stateful: instance baru tidak bisa langsung melayani
       request yang sedang berjalan

  2. Fast startup time
     ✓ Instance baru harus bisa melayani trafik dalam hitungan
       detik, bukan menit
     → Jika startup lambat: auto-scaling tidak bisa merespons
       lonjakan trafik dengan cepat

  3. Health check yang akurat
     ✓ Load balancer perlu tahu instance mana yang siap
     → Jika health check salah: trafik dikirim ke instance
       yang belum siap

  4. Graceful shutdown
     ✓ Instance yang dihapus harus bisa menyelesaikan request
       yang sedang ditangani sebelum mati
     → Jika tidak: request putus di tengah jalan saat scale in

Container dan arsitektur microservices sangat populer di cloud bukan tanpa alasan — keduanya secara natural mendorong pola stateless, startup yang cepat, dan deployment yang ringan. Ini semua adalah prasyarat untuk elasticity yang efektif.

Implikasi Biaya #

Pemahaman tentang elasticity langsung berdampak pada efisiensi biaya.

Skenario: Aplikasi web dengan pola trafik harian

  Trafik tinggi:  07:00–22:00 (15 jam) → butuh 10 instance
  Trafik rendah:  22:00–07:00 (9 jam)  → butuh 2 instance

  Tanpa Elasticity (selalu 10 instance):
    10 instance × 24 jam = 240 instance-jam/hari

  Dengan Elasticity:
    (10 × 15) + (2 × 9) = 150 + 18 = 168 instance-jam/hari

  Penghematan: 72 instance-jam/hari = ~30% lebih hemat
  Dan ini hanya untuk satu hari — berlipat ganda setiap bulan

Ringkasan #

Scalability = kemampuan untuk tumbuh — sistem bisa ditingkatkan kapasitasnya (scale up atau scale out) untuk mengakomodasi beban yang lebih besar.
Elasticity = adaptasi otomatis dua arah — kapasitas naik saat beban tinggi, turun saat beban rendah, secara otomatis tanpa intervensi manual.
Elasticity membutuhkan scalability sebagai fondasi — tapi tidak semua sistem scalable itu elastic.
Horizontal scaling adalah fondasi elasticity di cloud — vertical scaling memiliki batas dan tidak bisa di-automate seefektif horizontal scaling.
Stateless architecture adalah prasyarat elasticity — aplikasi yang menyimpan state di memori server tidak bisa di-scale out dengan mudah.
Elasticity adalah yang membuat pay-as-you-go benar-benar efisien — tanpa elasticity, kamu tetap membayar kapasitas puncak sepanjang waktu.

← Sebelumnya: Shared Responsibility Berikutnya: Global Infrastructure →