Dalam artikel sebelumnya sudah dijelaskan tentang database cluster arsitektur master slave dan contoh impelementasinya. Juga sudah dibahas tentang sharding database, maka kali ini kita akan bahas Kombinasi Database Cluster Master Slave dan Sharding Database untuk Solusi Jutaan Data. Sebagaimana kita sudah ketahui bahwa database cluster arsitektur master slave cocok digunakan untuk skala data menengah besar, akan tetapi untuk data yang sangat besar skala jutaan harus dikombinasikan dengan sharding atau master-master cluster.
Konsep master-slave cocok untuk baca banyak, tulis lebih sedikit → Master–Slave bagus kalau workload-nya lebih dominan SELECT (misalnya browsing produk, cari barang, lihat order history). Read scaling → dengan menambah banyak slave, beban baca bisa dibagi (load balancing SELECT). Data konsisten → karena slave mereplikasi data dari master, semua data akhirnya sama (eventual consistency). Jadi, jika user hanya lihat produk, search, kategori maka master-slave cocok.
Tantangan yang dihadapi saat data sudah sangat besar dengan pengguna juga sangat besar bahkan hingga jutaan:
- Bottleneck di Master (Write)
Semua INSERT/UPDATE/DELETE hanya lewat satu master → bisa jadi sempit kalau jutaan transaksi per detik (misalnya checkout, update stok, saldo, pembayaran). - Replication Lag
Slave mungkin terlambat sinkron dengan master → bisa muncul data tidak konsisten sesaat (misalnya stok masih terlihat tersedia padahal sudah habis di master). - Failover Rumit
Kalau master mati, harus ada mekanisme failover otomatis. Kalau tidak, aplikasi bisa downtime. - Skalabilitas Tulis (Write Scaling)
Master–Slave hanya menambah kapasitas read, bukan write. Jadi untuk e-commerce dengan jutaan transaksi write per hari → bisa bottleneck.
Solusi yang dapat dilakukan biasanya dipakai kombinasi strategi:
- Master–Slave + Sharding. Data dipartisi ke beberapa master–slave set. Misalnya: Cluster A → data produk elektronik. Cluster B → data fashion. Cluster C → data pembayaran. Dengan begitu, write load tersebar ke beberapa master.
- Master–Master (Multi-Primary Replication). MySQL Group Replication / Galera Cluster.. Semua node bisa write, otomatis replikasi antar node. Cocok untuk transaksi yang padat.
- Caching Layer. Gunakan Redis / Memcached untuk caching produk, kategori, session user. Mengurangi query langsung ke database.
- Search Engine terpisah. Produk biasanya ditaruh di Elasticsearch / OpenSearch supaya pencarian cepat (bukan dari database langsung).
- Message Queue (Kafka, RabbitMQ). Untuk transaksi besar (checkout, update stok) bisa pakai MQ supaya beban write ke database lebih terkontrol.
Jadi, untuk data yang sangat besar dengan jutaan pengguna, maka master-slave saja tidak cukup, karena hanya scaling baca (lihat produk, kategori, review). Sedangkan untuk write intensif (checkout, transaksi, saldo) → butuh Sharding. Atau multi-master cluster (MySQL Group Replication, Galera). Ditambah caching + search engine + message queue.
Tujuan
- Menangani read-heavy trafik (browsing, pencarian) sekaligus skala write tinggi (checkout, update stok)
- Minimalkan latency pada user-facing actions
- Jaga konsistensi data kritis (transaksi, saldo) sambil menerima eventual consistency di area lain
Komponen & Peran
- Load Balancer / CDN / WAF: terminasi TLS, rate limiting, cache static, WAF rules.
- Stateless App Servers: melayani request API; bersifat ephemeral — scale horizontally.
- Cache (Redis/Memcached): caching product list, session, cart, hot objects.
- Search Engine (Elasticsearch/OpenSearch): full-text search, aggregations, suggestion.
- Message Queue (Kafka/RabbitMQ): decouple write-heavy flows (checkout -> payment -> inventory updates -> downstream services).
- DB Shards: setiap shard adalah cluster master + N slaves untuk read scaling. Sharding mem-redistribute write load.
- Cluster Manager / Orchestrator: ProxySQL / HAProxy + Orchestrator untuk failover auto.
Kenapa gabungan ini?
- Master–Slave memberikan read scalability.
- Sharding memecah write load ke beberapa master sehingga scaling write.
- Cache & Search mengurangi beban baca langsung ke DB.
- MQ mengurangi beban write synchronous dan mempermudah retry / idempotency.
Strategi Sharding (contoh)
- Sharding berdasarkan tenant/seller: semua data vendor X disimpan di shard tertentu. Mudah untuk multi‑tenant isolation.
- Sharding berdasarkan range user_id / seller_id: user 1..1M -> shard A, 1M+ -> shard B.
- Hash-based sharding: consistent hashing pada user_id atau order_id.
- Pilih sesuai pola akses: jika permintaan biasanya per penjual, sharding by seller lebih efektif.
Konsistensi & Latency
Terima adanya replication lag: read-after-write dapat menunjukkan data lama jika baca dari slave.
Solusi:
- Untuk operasi sensitif (checkout, check saldo, availability), baca dari master atau gunakan cache yang diupdate setelah write.
- Gunakan optimistic locking / row versioning untuk race conditions.
- Implementasikan idempotency keys pada endpoints pembayaran.
Contoh Flow Checkout (high level)
- User submit checkout → App Server menerima.
- App Server menulis ke DB master shard terkait (order table) + push event ke MQ (order_created).
- Worker consumer (from MQ) memproses pembayaran, update inventory pada DB master, kirim email, update search index, dsb.
- Cache invalidation: hapus/update cache product stock & product listing.
- Slave akan mereplikasi data dari master secara asinkron.
Komponen Operasional & Observability
- Proxy/Orchestrator: ProxySQL, HAProxy, Orchestrator untuk manage failover.
- Monitoring: Prometheus + Grafana (monitor replication lag, QPS, latency, errors).
- Alerting: Alert pada replication lag > threshold, master down, queue backlog.
- Backups: Point-in-time recovery + regular snapshots per shard.
Contoh Koneksi PHP (concept snippet)
Di dokumen ini hanya snippet singkat untuk ide — implementasi harus menyesuaikan sharding map dan proxy.
// Pseudocode: pilih shard berdasarkan seller_id
function getShardConfigBySeller($seller_id) {
// contoh mapping sederhana
$shards = [
0 => ['host'=>'10.0.0.11','user'=>'root','pass'=>'pw','db'=>'shop_a'],
1 => ['host'=>'10.0.0.12','user'=>'root','pass'=>'pw','db'=>'shop_b'],
];
$idx = $seller_id % count($shards);
return $shards[$idx];
}
$cfg = getShardConfigBySeller($sellerId);
$mysqli = new mysqli($cfg['host'],$cfg['user'],$cfg['pass'],$cfg['db']);
// For reads, connect to read-proxy or slave list (ProxySQL)
// For writes, connect to master-proxy
Rekomendasi Praktis
- Jangan gunakan master–slave saja jika Anda mengantisipasi write-heavy growth. Rencanakan sharding dan CQRS pattern.
- Gunakan Redis untuk stock preview / temporary locks, tapi pastikan authoritative source tetap DB master.
- Test failure scenarios (promote master, network partition).
- Optimalkan schema & indexes, gunakan partitioning untuk very large tables.