Scalability #

Dalam sistem backend modern, database hampir selalu menjadi bottleneck utama ketika traffic dan volume data mulai meningkat. Banyak aplikasi terlihat baik-baik saja di awal, namun mulai melambat, timeout, atau bahkan down ketika user bertambah, data membesar, dan query semakin kompleks.

Di sinilah konsep scalability menjadi krusial. Artikel ini membahas secara mendalam:

Apa itu scalability
Mengapa scalability di level database sangat penting
Perbedaan vertical scalability dan horizontal scalability
Implementasi nyata scalability di database
Best practice yang sering diabaikan namun berdampak besar

Artikel ini ditulis dengan sudut pandang praktis: apa yang benar-benar terjadi di lapangan dan kesalahan umum yang sering menyebabkan database tidak scalable.

Apa Itu Scalability? #

Scalability adalah kemampuan sistem untuk menangani peningkatan beban (load) tanpa mengalami degradasi performa yang signifikan.

Di level database, beban ini biasanya berupa:

Jumlah query per detik (QPS)
Volume data yang terus bertambah
Query yang semakin kompleks
Concurrent connection yang meningkat

Database yang scalable mampu:

Tetap cepat saat data tumbuh dari ribuan ke miliaran row
Tetap stabil saat user meningkat drastis
Tidak memerlukan rewrite besar setiap kali skala naik

Scalability berbeda dengan performance:

Performance → seberapa cepat sistem saat ini
Scalability → seberapa baik sistem saat beban meningkat

Database bisa cepat hari ini, tapi tidak scalable untuk besok.

Mengapa Scalability di Level Database Sangat Penting? #

Beberapa alasan utama:

Database adalah Shared Resource #

Semua service bergantung pada database:

API
Worker
Cron
Admin panel

Satu query lambat dapat mempengaruhi seluruh sistem.

Scaling Database Lebih Sulit dari Scaling Service #

Scaling backend stateless service relatif mudah. Scaling database:

Mahal
Kompleks
Penuh trade-off (consistency, latency, operational cost)

Kesalahan Desain Awal Sulit Diperbaiki #

Contoh kesalahan fatal:

Tidak memikirkan index sejak awal
Query bergantung pada COUNT(*) besar
Tabel tumbuh tanpa strategi partition

Semua ini membuat scalability menjadi utang teknis besar.

Dua Pendekatan Utama Scalability Database #

Secara umum, ada dua pendekatan:

Vertical Scalability (Scale Up)
Horizontal Scalability (Scale Out)

Keduanya bukan saling menggantikan, tapi sering dikombinasikan.

Vertical Scalability (Scaling Up) #

Apa Itu Vertical Scalability? #

Vertical scalability adalah meningkatkan kapasitas satu node database dengan cara:

Menambah CPU
Menambah RAM
Menggunakan storage lebih cepat (NVMe, SSD)

Contoh:

Dari 4 CPU → 16 CPU
Dari 16 GB RAM → 64 GB RAM

Kelebihan Vertical Scalability #

Implementasi paling mudah
Tidak perlu perubahan besar di aplikasi
Cocok untuk sistem kecil–menengah

Kekurangan Vertical Scalability #

Ada batas maksimum hardware
Semakin mahal secara eksponensial
Single point of failure
Tidak menyelesaikan masalah arsitektural

Vertical scaling sering hanya menunda masalah, bukan menyelesaikannya.

Kapan Vertical Scaling Masuk Akal? #

MVP atau early-stage product
Traffic masih relatif rendah
Bottleneck jelas di resource (CPU/RAM)
Belum siap kompleksitas distributed system

Namun, jangan mengandalkan vertical scaling sebagai strategi jangka panjang.

Horizontal Scalability (Scaling Out) #

Apa Itu Horizontal Scalability? #

Horizontal scalability adalah meningkatkan kapasitas database dengan:

Menambah node
Membagi beban data atau query
Mendukung distributed workload

Pendekatan ini jauh lebih kompleks, tapi lebih sustainable.

Bentuk Implementasi Horizontal Scalability #

Read Replica (Read Scaling) #

Satu primary (write)
Banyak replica (read)

Digunakan untuk:

Dashboard
Report
Admin panel
Query berat non-transaksional

Catatan penting:

Replica bersifat eventually consistent
Jangan gunakan untuk data yang butuh real-time consistency

Database Sharding #

Data dibagi ke beberapa database berdasarkan shard key:

user_id
region
tenant_id

Contoh:

user_id % 4 → shard 0–3

Kelebihan:

Skala data dan write
Mengurangi ukuran tabel per shard

Kekurangan:

Query lintas shard kompleks
Transaction lintas shard sulit
Operational complexity tinggi

Partitioning (Table-Level Scalability) #

Partitioning membagi tabel besar menjadi beberapa bagian:

By range (tanggal)
By hash
By list

Manfaat:

Query lebih cepat
Index lebih kecil
Maintenance lebih mudah

Partitioning bukan sharding, tapi sering jadi langkah awal sebelum sharding.

CQRS (Command Query Responsibility Segregation) #

Pisahkan:

Database untuk write
Database untuk read

Biasanya dikombinasikan dengan:

Event-driven architecture
Async replication

Cocok untuk sistem dengan read-heavy workload.

Best Practice Scalability di Level Database #

Desain Query untuk Skala, Bukan untuk Mudah #

Hindari SELECT *
Hindari COUNT(*) besar di runtime
Batasi pagination berbasis offset besar

Query yang nyaman ≠ query yang scalable.

Indexing dengan Strategi, Bukan Insting #

Index mengikuti access pattern
Jangan over-index
Audit index secara berkala

Index yang salah bisa memperlambat write dan replication.

Kurangi Beban Database Sejak Awal #

Cache hasil query (Redis)
Gunakan async processing
Hindari query di loop (N+1)

Database seharusnya opsi terakhir, bukan default.

Pisahkan Beban OLTP dan OLAP #

OLTP → transaksi harian
OLAP → reporting, analytics

Jangan jalankan query report berat di database transaksi.

Observability adalah Kunci #

Tanpa visibility, scalability hanya tebakan:

Slow query log
Query latency
Connection usage
Lock dan wait time

Scalability tanpa observability = blind scaling.

Scale Bertahap, Jangan Over-Engineer #

Mulai dari vertical
Optimasi query
Tambahkan replica
Baru pertimbangkan sharding

Over-engineering sejak awal sering lebih berbahaya daripada under-scaling.

Kesalahan Umum dalam Scalability Database #

Mengandalkan hardware untuk menutupi query buruk
Menganggap ORM otomatis scalable
Menjalankan analytic query di production DB
Tidak memikirkan growth data

Scalability gagal bukan karena database-nya, tapi karena desain dan kebiasaan developer.

Penutup #

Scalability di level database adalah kombinasi antara:

Arsitektur
Disiplin query
Pemahaman workload
Trade-off yang disadari

Tidak ada solusi tunggal yang sempurna. Yang ada adalah keputusan teknis yang tepat untuk konteks yang tepat.

Database yang scalable bukan yang paling canggih, tapi yang dirancang dengan kesadaran akan masa depan.