EVENT-SOURCING CQRS EVENT-DRIVEN ARCHITECTURE DISTRIBUTED-SYSTEMS SCALABILITY DATA-INTEGRITY AUDITABILITY MICROSERVICES BACKEND DESIGN-PATTERNS

Menggali Lebih Dalam Event Sourcing dan CQRS: Fondasi Sistem yang Auditabel dan Skalabel

⏱️ 13 menit baca
👨‍💻

Menggali Lebih Dalam Event Sourcing dan CQRS: Fondasi Sistem yang Auditabel dan Skalabel

Halo, para developer! Pernahkah Anda merasa frustrasi saat mencoba melacak setiap perubahan data di aplikasi Anda? Atau mungkin Anda menghadapi masalah performa ketika harus menampilkan data yang sama dalam berbagai format yang berbeda? Jika ya, Anda tidak sendirian. Aplikasi web modern seringkali menghadapi tantangan ini, terutama ketika mereka tumbuh dan menjadi lebih kompleks.

Dalam artikel sebelumnya, kita sudah membahas tentang [Event-Driven Architecture (EDA)](Event-Driven Architecture (EDA): Membangun Aplikasi Responsif dan Skalabel) yang membantu kita membangun sistem yang lebih responsif dan skalabel dengan berinteraksi melalui event. Nah, hari ini kita akan melangkah lebih jauh, menyelami dua pola arsitektur yang seringkali menjadi “pasangan serasi” di dunia event-driven: Event Sourcing (ES) dan Command Query Responsibility Segregation (CQRS).

Kedua pola ini mungkin terdengar rumit, tetapi mereka menawarkan solusi elegan untuk masalah auditabilitas, skalabilitas, dan fleksibilitas data yang sering menghantui aplikasi kita. Mari kita bongkar satu per satu!

1. Pendahuluan: Mengapa Kita Butuh Event Sourcing dan CQRS?

Dalam model aplikasi tradisional, kita biasanya menyimpan state atau status terakhir dari sebuah entitas. Misalnya, jika Anda punya akun bank, yang disimpan di database adalah saldo terakhir Anda. Ketika ada transaksi, saldo itu langsung di-update.

Masalahnya?

Di sinilah Event Sourcing dan CQRS masuk. Mereka bukan sekadar “tambahan” pada aplikasi Anda, melainkan cara berpikir ulang tentang bagaimana data disimpan dan diakses. Dengan mengadopsi pola ini, kita bisa membangun sistem yang tidak hanya lebih skalabel dan performan, tetapi juga memiliki jejak audit yang tak terbantahkan.

2. Memahami Event Sourcing: Bukan Sekadar Logging Biasa

📌 Apa itu Event Sourcing?

Bayangkan Anda memiliki buku besar akuntansi. Setiap transaksi — uang masuk, uang keluar — dicatat sebagai entri baru yang tidak dapat diubah. Saldo akhir Anda adalah hasil dari semua entri tersebut yang dihitung secara berurutan.

Itulah inti dari Event Sourcing. Alih-alih menyimpan status terakhir dari sebuah objek (misalnya, saldo akun bank), Event Sourcing menyimpan semua event (kejadian) yang menyebabkan perubahan pada objek tersebut. Setiap kali ada sesuatu yang terjadi, sebuah “event” baru dicatat dan ditambahkan ke “event store” (penyimpanan event) sebagai fakta yang tidak dapat diubah. State saat ini dari objek tersebut kemudian “dibangun ulang” dengan memutar ulang (replay) semua event secara berurutan.

Analogi Konkret: Anggaplah Anda punya akun bank.

💡 Komponen Utama Event Sourcing:

Contoh Struktur Event (konseptual):

// Event: PesananDibuat
{
  "eventId": "e6a7b8c9-d0e1-4f2a-b3c4-d5e6f7a8b9c0",
  "timestamp": "2023-10-27T10:00:00Z",
  "eventType": "PesananDibuat",
  "payload": {
    "orderId": "ORD-001",
    "userId": "user-A",
    "items": [
      {"productId": "prod-X", "qty": 2, "price": 100000}
    ]
  },
  "metadata": {
    "source": "WebApp",
    "ipAddress": "192.168.1.1"
  }
}

// Event: ItemDitambahkanKePesanan
{
  "eventId": "f1g2h3i4-j5k6-7l8m-9n0o-1p2q3r4s5t6u",
  "timestamp": "2023-10-27T10:05:00Z",
  "eventType": "ItemDitambahkanKePesanan",
  "payload": {
    "orderId": "ORD-001",
    "productId": "prod-Y",
    "qty": 1,
    "price": 50000
  },
  "metadata": {
    "source": "WebApp",
    "ipAddress": "192.168.1.1"
  }
}

// ... event lainnya yang mengubah state pesanan ORD-001

✅ Keuntungan Event Sourcing:

⚠️ Tantangan Event Sourcing:

3. Memecah Monolit Data dengan CQRS (Command Query Responsibility Segregation)

🎯 Apa itu CQRS?

CQRS adalah pola arsitektur yang memisahkan model untuk operasi menulis data (Commands) dan operasi membaca data (Queries). Artinya, Anda tidak lagi menggunakan satu model data atau database yang sama untuk kedua jenis operasi tersebut.

Analogi Konkret: Bayangkan sebuah restoran.

Command Side (Write Model)

Query Side (Read Model)

✅ Keuntungan CQRS:

⚠️ Tantangan CQRS:

4. Sinergi Event Sourcing dan CQRS: Kombinasi Kuat

Ketika Event Sourcing dan CQRS digabungkan, mereka membentuk sebuah arsitektur yang sangat kuat dan fleksibel. Event Sourcing menyediakan sumber kebenaran yang tak terbantahkan (Event Store), sementara CQRS memanfaatkan event-event ini untuk membangun model baca yang sangat dioptimalkan.

Bagaimana Keduanya Bekerja Sama:

  1. Command Diterima: Aplikasi menerima Command (misal: BuatPesanan).
  2. Aggregate Memproses: Aggregate yang relevan (misal: Aggregate Pesanan) memvalidasi Command dan menghasilkan satu atau lebih Events (misal: PesananDibuat).
  3. Events Disimpan: Events ini disimpan secara berurutan ke Event Store.
  4. Events Dipublikasikan: Setelah disimpan, Events dipublikasikan (melalui Message Broker seperti Kafka atau RabbitMQ) agar dapat didengarkan oleh komponen lain.
  5. Read Models Mengkonsumsi: Read Models (proyeksi) mendengarkan Events ini. Setiap Read Model memproses Events yang relevan untuk membangun dan mengupdate datanya sendiri, yang dioptimalkan untuk query spesifik.
  6. Query ke Read Models: Ketika aplikasi membutuhkan data, ia melakukan Query ke Read Model yang sesuai.

Diagram Alur Kerja Sederhana:

[User Interface] --Command--> [Command Handler] --> [Aggregate] --> [Event Store]
                                                           |
                                                           V
                                                 [Event Bus/Message Broker]
                                                           |
                                                           V
                   [Read Model Projector 1] <---Events--- [Read Model Projector 2]
                             |                                     |
                             V                                     V
                     [Read Database 1]                       [Read Database 2]
                             ^                                     ^
                             |                                     |
                             --Query--> [User Interface] <--Query--

Contoh: Aplikasi E-commerce

Dengan kombinasi ini, Anda mendapatkan sistem yang sangat fleksibel: setiap perubahan state direkam secara permanen (Event Sourcing), dan data dapat disajikan dalam berbagai format yang sangat dioptimalkan untuk query (CQRS).

5. Kapan Menggunakan Event Sourcing dan CQRS?

Meskipun kuat, Event Sourcing dan CQRS bukanlah silver bullet untuk setiap masalah. Menerapkannya secara tidak tepat bisa menambah kompleksitas yang tidak perlu.

✅ Cocok untuk:

❌ Tidak Cocok untuk:

6. Tips Praktis dan Best Practices

💡 Jika Anda memutuskan untuk menyelami Event Sourcing dan CQRS, berikut beberapa tips untuk membantu perjalanan Anda: