Anti-Pattern Database: Read Replica Menganggur dan Salah Kaprah Penggunaannya

Dalam arsitektur database modern, keberadaan read replica (slave) sering dianggap sebagai tanda sistem yang sudah scalable dan mature. Namun dalam praktiknya, tidak sedikit sistem yang justru jatuh ke dalam anti-pattern: read replica tersedia tetapi hampir tidak digunakan, atau lebih buruk lagi, hanya dipakai oleh tim data, sementara aplikasi tetap sepenuhnya membaca dari master.

Kondisi ini bukan hanya suboptimal, tetapi secara fundamental salah secara arsitektur dan pemborosan secara biaya. Read replica yang idle dengan utilisasi sangat rendah bukanlah safety net, melainkan indikasi desain yang tidak tuntas.

Artikel ini secara tegas membahas:

• mengapa read replica yang tidak digunakan adalah anti-pattern
• mengapa penggunaan read replica oleh tim data adalah kesalahan desain
• bagaimana seharusnya read replica dan data warehouse ditempatkan
• serta strategi menghadapi isu konsistensi tanpa mengorbankan skalabilitas

Memahami Realita Konsistensi pada Read Replica

Asynchronous Replication adalah Default

Sebagian besar managed database (MySQL, PostgreSQL, RDS, Aurora) menggunakan asynchronous replication untuk read replica. Konsekuensinya:

• Write selalu masuk ke master
• Read replica menerima perubahan dengan delay
• Delay ini disebut replication lag

Replication lag:

• normal
• tidak bisa dihilangkan sepenuhnya
• harus dihadapi secara arsitektural

Read replica bukan salinan real-time, melainkan eventually consistent copy.

Ketidaksinkronan Read–Write: Masalah atau Karakteristik?

Replication lag sering diperlakukan sebagai masalah, padahal sebenarnya ini adalah karakteristik sistem terdistribusi.

Pertanyaan yang tepat bukan:

“Bagaimana menghilangkan replication lag?”

Melainkan:

“Read mana yang benar-benar membutuhkan strong consistency?”

Konsistensi Itu Masalah Use Case, Bukan Alasan Menolak Arsitektur

Strong consistency tidak dibutuhkan di semua tempat. Banyak read bersifat informatif dan toleran terhadap delay.

Contoh read yang tidak membutuhkan strong consistency:

• dashboard
• list data
• feed
• search result
• reporting

Solusi arsitektur yang matang:

• critical read → master
• non-critical read → slave

Strategi Menghadapi Read–Write Tidak Sinkron

Berikut beberapa strategi yang umum dan terbukti efektif.

Read Your Own Write (RYOW)

• Setelah write, read dilakukan ke master
• Read berikutnya (setelah jeda) boleh ke replica

Digunakan untuk:

• update profile
• submit form

Read Routing Berdasarkan Use Case

Pisahkan secara eksplisit:

• critical read → master
• non-critical read → replica

Ini bisa dilakukan di:

• application layer
• repository layer
• API gateway

Time-Based Routing

• Read dalam window tertentu setelah write (misalnya 1–2 detik) diarahkan ke master
• Setelah itu, dialihkan ke replica

Strategi ini sederhana dan efektif untuk banyak use case.

Monitoring Replication Lag

Gunakan metric:

• replication delay
• replica I/O

Jika lag melewati threshold tertentu:

• fallback read ke master

Ini menjadikan sistem adaptive, bukan statis.

Read Replica yang Tidak Digunakan adalah Anti-Pattern

Read replica bukan komponen opsional atau cadangan pasif. Ia dibuat untuk secara aktif digunakan oleh aplikasi.

Read replica yang:

• tidak menerima traffic aplikasi
• hanya dipakai untuk query data sesekali
• memiliki utilisasi CPU single-digit

menunjukkan bahwa arsitektur database tidak memanfaatkan komponen yang dibayar penuh.

Secara prinsip:

Jika sebuah read replica tidak dipakai untuk offload read aplikasi, maka keberadaannya perlu dipertanyakan.

Isolasi Query Berat

• Query list panjang
• Query join kompleks (non-analytics)

Replica melindungi master dari query yang mahal.

Scalability untuk Read-Heavy System

Pada sistem dengan rasio read:write tinggi:

• replica memberikan ROI yang sangat besar
• latency aplikasi lebih stabil

Mengapa Menggunakan Read Replica untuk Tim Data adalah Kesalahan

OLTP vs OLAP Bukan Sekadar Istilah

Tim data secara alami berada di domain OLAP.

Mengapa Tim Data Idealnya Fully di Data Warehouse

Query Analytics Mahal untuk OLTP

• Full table scan
• Heavy join
• Long-running query

Semua ini:

• mahal di OLTP
• murah dan natural di OLAP

Data Warehouse Dirancang untuk Skalabilitas Query

• Columnar storage
• Parallel execution
• Optimized aggregation

Hal yang tidak dimiliki database transactional.

Clear Separation of Responsibility

• OLTP: melayani aplikasi
• OLAP: melayani analitik

Boundary yang jelas:

• menurunkan risiko
• mempermudah cost control

Pola Arsitektur yang Sehat

Arsitektur yang matang biasanya memiliki pola:

• Aplikasi:

  • write → master
  • read → master / replica (berdasarkan use case)

• Data pipeline:

  • master → warehouse (CDC / ETL)

• Tim data:

  • query → warehouse

Query langsung ke OLTP oleh tim data hanya bersifat:

• ad-hoc
• debugging
• temporer

Dampak Langsung terhadap Cost dan Reliability

Dengan pemisahan yang jelas:

• Beban master turun
• Replica punya utilitas nyata
• Warehouse digunakan sesuai perannya
• Biaya database lebih terkontrol

Cost reduction datang sebagai efek samping dari desain yang benar, bukan pemotongan paksa.

Penutup

Ketidaksinkronan read–write bukan alasan untuk menghindari read replica, melainkan sinyal bahwa sistem perlu strategi konsistensi yang jelas.

Read replica, jika digunakan dengan tepat:

• meningkatkan scalability
• menurunkan cost jangka panjang

Dan data warehouse:

• seharusnya menjadi pusat analitik
• bukan pelengkap yang setengah dipakai

Arsitektur database yang sehat bukan soal menambah komponen, tetapi menempatkan setiap komponen di peran yang tepat.