Penerapan CQRS dan Event Sourcing di Sistem Monolit: Overkill atau Persiapan Evolusi yang Tepat?

Gambar ini: startup lo lagi jalan dengan monolit yang solid. Tapi, fitur baru butuh query yang kompleks dan bikin performa utama anjlok. Solusi klasik: scaling database atau caching. Tapi ada opsi lain yang radikal: menerapkan CQRS (Command Query Responsibility Segregation) dan Event Sourcing di dalam monolit itu sendiri. Banyak yang bilang ini overkill untuk monolit. Benarkah?

CQRS & ES dalam Monolit: Apa yang Terjadi?
Intinya, lo mulai memisahkan jalur penulisan (Command) dan jalur pembacaan (Query) di level aplikasi, meski databasenya masih satu. Alih-alih langsung update tabel, setiap “peristiwa bisnis” (Event) direkam sebagai log yang immutable. Dari log event inilah, “state” atau tampilan data (Query Model) dibangun ulang secara proyeksi. Di monolit, lo bisa implementasi pola ini tanpa microservices, bahkan mungkin masih pakai database relational yang sama (dengan tabel terpisah untuk event store dan query model).

Kenapa Lo Mau Lakukan Ini?

  1. Skalabilitas Selective: Lo bisa scaling sisi Query secara independen (misal, pake database read replica atau caching agresif) tanpa ganggu sisi Command yang kritis.
  2. Audit Trail Bawaan: Event Sourcing menyimpan setiap perubahan sebagai event. Lo tau persis apa yang terjadi, kapan, dan oleh siapa. Ini gold untuk debugging dan compliance.
  3. Jembatan ke Masa Depan: Ini adalah persiapan evolusi yang sempurna. Ketika monolit lo nantinya perlu dipecah, bounded context sudah jelas dari event-nya. Migrasi ke arsitektur yang lebih terdistribusi jadi jauh lebih mulus karena “sumber kebenaran” (event log) sudah ada.

Jebakan dan Kapan Itu Overkill?
Ini memang kompleks. Lo memperkenalkan eventual consistency ke sistem yang mungkin sebelumnya strongly consistent. Lo juga butuh handler untuk memproyeksikan event ke query model. Ini overkill jika: kebutuhan bisnis lo sederhana, tim kecil, dan belum ada masalah skalabilitas atau traceability yang nyata. Tapi, jika lo merasakan bottleneck query yang parah, membutuhkan kemampuan “time travel” data, atau memprediksi perlu memecah monolit dalam 1-2 tahun ke depan, memulai dengan CQRS/ES di dalam monolit adalah strategi persiapan yang cerdas, bukan overkill. Lo membayar kompleksitas di awal untuk fleksibilitas dan ketahanan di masa depan.