Case Study July 2026

Database Replication Strategies: Master-Slave & Master-Master

As the number of users grows, a single database server won't be enough. This article discusses why we need replication, its types, and best practices on when to use them.

1Why Do We Need Replication?

Imagine your app is a huge success. Daily Active Users (DAU) skyrocket. Suddenly, the app feels sluggish. Upon checking, your database server's CPU and Memory are constantly hitting 100%. You've tried Vertical Scaling (adding RAM/CPU to the server), but it reaches a hard limit, and the cost becomes exponential.

Main Reasons (Horizontal Scaling):

High Availability (Ketersediaan): Jika satu server database mati (down), aplikasi tetap hidup karena data ada di server lain.
Load Balancing (Skalabilitas): Beban membaca (Read) dan menulis (Write) dapat didistribusikan ke beberapa server, mencegah bottleneck.
Disaster Recovery (Backup): Jika data center utama bermasalah, data masih aman di lokasi (node) lain.

2Master - Slave (Read Replicas)

This configuration (also often called Primary - Replica) is the most commonly found in startups.

Master (Primary): Satu-satunya server yang boleh menerima perintah INSERT, UPDATE, dan DELETE.
Slave (Replica): Hanya boleh melayani permintaan SELECT (Read-Only). Semua data dari Master disalin ke Slave secara otomatis.

Best Practice / Kapan digunakan?

Use this when your app is Read-Heavy (e.g., Blogs, E-commerce, Social Media). Usually, the read:write ratio is 80:20. You can have 1 Master and 5 Slaves to handle traffic spikes during a Flash Sale.

3Master - Master (Multi-Primary)

In this architecture, you have more than one server that all act as Masters. Meaning, two or more servers can accept WRITE commands simultaneously.

Kelebihan: Menghilangkan Single Point of Failure (SPOF) untuk operasi WRITE. Jika Master 1 mati, Master 2 siap menerima WRITE.
Kelemahan: Risiko konflik data (Collision). Bagaimana jika User A update saldo di Master 1, sementara di waktu yang sama persis User B menarik saldo User A dari Master 2? Solusinya sangat rumit.

Best Practice / Kapan digunakan?

Suitable for systems that are Write-Heavy and geographically distributed (e.g., Master 1 in Jakarta, Master 2 in Singapore). But avoid this if you aren't adept at handling data conflicts; it's often better to consider a Sharding architecture.