CQRS Architecture #

Seiring bertambahnya kompleksitas aplikasi modern—terutama aplikasi berskala besar, high-traffic, dan data-intensive—pendekatan arsitektur tradisional sering kali menemui keterbatasan. Salah satu masalah umum adalah ketika satu model domain dipaksa untuk melayani dua kebutuhan yang sangat berbeda: operasi baca (query) dan operasi tulis (command).

CQRS (Command Query Responsibility Segregation) hadir sebagai pendekatan arsitektur yang memisahkan secara tegas tanggung jawab antara operasi membaca dan menulis data. Pemisahan ini memungkinkan sistem untuk dioptimalkan secara independen sesuai kebutuhan masing-masing.

Sebagai gambaran awal, berikut bagan sederhana CQRS secara text-based:

           +-------------+
           |   Client    |
           +------+------+ 
                  |
        +---------+---------+
        |                   |
   (Command)            (Query)
        |                   |
+-------v-------+   +-------v-------+
| Command Model |   |  Query Model  |
| (Write Side)  |   |  (Read Side)  |
+-------+-------+   +-------+-------+
        |                   |
+-------v-------+   +-------v-------+
| Write Database|   |  Read Database|
+---------------+   +---------------+

Dari bagan di atas terlihat jelas bahwa jalur penulisan dan pembacaan data dipisahkan, baik dari sisi model maupun penyimpanan data.

Apa itu CQRS Architecture? #

CQRS (Command Query Responsibility Segregation) adalah pola arsitektur yang memisahkan:

• Command → operasi yang mengubah state sistem (Create, Update, Delete)
• Query → operasi yang mengambil data tanpa mengubah state

Prinsip utamanya adalah:

Satu model tidak seharusnya digunakan sekaligus untuk membaca dan menulis.

Dalam CQRS:

• Command side berfokus pada validasi bisnis dan konsistensi data
• Query side berfokus pada performa dan kemudahan membaca data

CQRS sering (namun tidak wajib) dikombinasikan dengan Event Sourcing, di mana perubahan state disimpan sebagai rangkaian event.

Tujuan Architecture #

Tujuan utama dari CQRS adalah:

1. Separation of Concerns Memisahkan kompleksitas logic tulis dan baca agar masing-masing lebih sederhana dan fokus.

2. Scalability Read side dan write side dapat di-scale secara independen sesuai beban.

3. Performance Optimization Query dapat menggunakan model, schema, dan database yang dioptimalkan khusus untuk membaca.

4. Flexibility in Data Modeling Struktur data read model tidak harus mengikuti domain model.

5. Better Domain Integrity Write model bisa sangat ketat terhadap aturan bisnis tanpa mengorbankan performa query.

Kapan Cocok Digunakan? #

CQRS tidak selalu diperlukan. Arsitektur ini paling cocok digunakan ketika:

• Aplikasi memiliki perbedaan signifikan antara kompleksitas baca dan tulis
• Sistem berskala besar dengan traffic read jauh lebih tinggi daripada write
• Domain bisnis kompleks dan penuh aturan (misalnya: finance, e-commerce, logistics)
• Diperlukan high performance query (dashboard, reporting, analytics)
• Sistem menggunakan atau berencana menggunakan event-driven architecture

CQRS kurang cocok untuk:

• Aplikasi CRUD sederhana
• Tim kecil dengan pengalaman terbatas
• Proyek dengan time-to-market yang sangat ketat

Pros dan Cons #

✅ Pros #

1. Scalability yang Sangat Baik Read dan write dapat di-scale terpisah.

2. Model Lebih Jelas dan Fokus Command model fokus ke bisnis, query model fokus ke data retrieval.

3. Performa Query Tinggi Read model bisa di-denormalisasi atau disesuaikan dengan kebutuhan UI.

4. Cocok untuk Event-Driven System Mudah dikombinasikan dengan Event Sourcing dan message broker.

5. Lebih Mudah Dimaintain pada Skala Besar Kompleksitas terbagi dengan lebih terstruktur.

❌ Cons #

1. Kompleksitas Arsitektur Lebih banyak komponen dan alur data.

2. Eventual Consistency Read model mungkin tidak langsung sinkron dengan write model.

3. Overhead Infrastruktur Biasanya membutuhkan message broker, worker, dan database tambahan.

4. Learning Curve Tinggi Tidak semua developer familiar dengan CQRS.

5. Debugging Lebih Sulit Alur data tidak lagi linear.

Informasi Tambahan yang Perlu Diketahui #

• CQRS sering digunakan bersama:

  • DDD (Domain-Driven Design)
  • Event Sourcing
  • Microservices Architecture

• CQRS bukan silver bullet. Nilainya terasa ketika domain dan skala sistem memang membutuhkannya.

• Banyak sistem besar (misalnya e-commerce dan financial systems) mengadopsi CQRS secara parsial, bukan menyeluruh.

Best Practice #

1. Mulai dari Simple CQRS Tidak wajib langsung memisahkan database. Pisahkan model dan handler terlebih dahulu.

2. Gunakan Naming yang Jelas Gunakan istilah CommandHandler, QueryHandler, ReadModel, dll.

3. Jangan Paksa Event Sourcing CQRS bisa berdiri sendiri tanpa Event Sourcing.

4. Optimalkan Read Model untuk Use Case Jangan ragu melakukan denormalisasi di read side.

5. Perhatikan Consistency Requirement Pastikan stakeholder memahami konsekuensi eventual consistency.

6. Gunakan Message Broker yang Andal Kafka, RabbitMQ, Pub/Sub, atau SQS sangat umum digunakan.

7. Monitoring dan Observability Logging, tracing, dan metrics menjadi sangat penting.

Penutup #

CQRS Architecture menawarkan pendekatan yang sangat kuat untuk menangani kompleksitas dan skalabilitas sistem modern dengan memisahkan secara tegas tanggung jawab baca dan tulis. Dengan pemisahan ini, sistem menjadi lebih fleksibel, scalable, dan siap berkembang.

Namun, kekuatan tersebut datang dengan harga berupa kompleksitas tambahan. Oleh karena itu, keputusan menggunakan CQRS harus didasarkan pada kebutuhan nyata, bukan tren.

Jika diterapkan pada konteks yang tepat dan dengan best practice yang baik, CQRS dapat menjadi fondasi arsitektur yang sangat solid untuk aplikasi berskala besar dan berumur panjang.