Sharding dan Read Replicas: Cara Database Menangani Jutaan User

Batas Maksimal Sebuah Komputer Fisik

Kamu meluncurkan aplikasi sosial mediamu, dan tiba-tiba 1 juta orang mendaftar dalam semalam. Server *Database* MySQL-mu yang berada di VPS RAM 8GB mulai terbakar (CPU 100%). *Query* SELECT menjadi sangat lambat. Bagaimana cara para *Backend Architect* menyelamatkan situasi ini (Scaling)?

Langkah 1: Vertical Scaling (Beli Komputer Sultan)

Cara paling instan dan paling bodoh. Matikan servernya, upgrade langganan AWS-mu ke server dewa dengan RAM 512GB dan prosesor 128 Core. Database-mu akan ngebut lagi.
Kelemahan: Ada batas fisika maksimum sekeping *motherboard* komputer. Dan harga server sultan ini naiknya eksponensial (ratusan juta rupiah sebulan).

Langkah 2: Read Replicas (Membelah Tugas Baca dan Tulis)

Jika kita perhatikan aplikasi nyata (seperti Twitter), aktivitas Membaca Data (GET) itu 10x lipat lebih banyak dibandingkan aktivitas Menulis Data (POST/INSERT). Orang lebih sering men-scroll *timeline* daripada menulis status baru.

Untuk meringankan beban, kita membuat Read Replicas (Salinan Pembaca).

• Kita beli 1 Komputer Utama (Master/Primary). Komputer ini HANYA boleh menerima instruksi INSERT, UPDATE, DELETE.
• Kita beli 3 Komputer Murah (Slave/Read Replicas). Ketiga komputer ini akan dikloning datanya secara *Real-Time* dari Komputer Utama secara otomatis.
• Di kodemu, semua SELECT API diarahkan (di-*Load Balance*) ke 3 Komputer Murah tersebut. Kini beban *Database* terbagi rata, dan kecepatan baca meningkat 300%!

Langkah 3: Database Sharding (Membelah Tabel Raksasa)

Bagaimana jika masalahnya bukan banyak yang baca, tapi jumlah baris data di Tabel *Users* sudah mencapai 1 Miliar Baris? Menyimpan tabel raksasa di satu mesin akan membuat proses Update memakan waktu berjam-jam (Index membengkak).

Solusi pamungkasnya adalah Sharding (Memecah Kaca). Arsitektur ini memotong tabel secara horizontal ke banyak *server* terpisah (Horizontal Scaling).

• Beli 4 Server Database terpisah.
• Server 1: Menyimpan *User* yang namanya berawalan huruf A - F.
• Server 2: Menyimpan *User* huruf G - L, dan seterusnya.

Saat aplikasi menembak API "Cari Budi", logika aplikasimu akan melihat bahwa Budi berawalan 'B', sehingga kodemu akan langsung menembak Server 1 saja tanpa mengganggu tiga server lainnya! Pencarian yang tadinya menelusuri 1 Miliar baris, kini menyusut jadi hanya menelusuri 250 juta baris. Inilah sihir *System Design* tingkat akhir!