Mengenal Konsep Event Sourcing: Catatan Perubahan Setiap Langkah
Pernah nggak sih kamu merasa kesal karena aplikasi yang kamu pakai tiba-tiba error, dan data yang sudah kamu masukkan hilang begitu saja? Atau mungkin kamu penasaran bagaimana sistem perbankan bisa melacak transaksi puluhan tahun lalu dengan detail? Nah, di sinilah konsep Event Sourcing memainkan perannya.
Bayangkan kamu sedang bermain game RPG. Setiap kali kamu mengambil item, mengalahkan monster, atau naik level, game tersebut menyimpan semua riwayat aksi kamu. Bukan hanya menyimpan status karakter terakhir, tapi semua peristiwa yang terjadi. Itulah gambaran sederhana dari Event Sourcing.
Apa Itu Event Sourcing?
Secara sederhana, Event Sourcing adalah pendekatan penyimpanan data di mana kita menyimpan setiap perubahan (event) yang terjadi pada suatu data, bukan hanya menyimpan state atau kondisi terakhirnya. Jadi kalau biasanya di database kita punya tabel “User” dengan kolom nama, email, dan status, dengan Event Sourcing kita akan punya kumpulan event seperti “UserRegistered”, “EmailUpdated”, “OrderPlaced”, dan seterusnya.
Misalnya di aplikasi e-commerce. Pendekatan tradisional akan menyimpan data pesanan terakhir: pesanan dengan status “dikirim”. Tapi dengan Event Sourcing, kita menyimpan seluruh rangkaian: “PesananDibuat”, “PembayaranDiterima”, “BarangDikemas”, “BarangDikirim”, dan seterusnya. Semua peristiwa ini disimpan secara berurutan.
Kenapa Harus Ribet-Ribet?
Mungkin kamu bertanya, “Kenapa nggak simpan aja data terakhir? Kan lebih simpel.” Iya, untuk aplikasi sederhana memang lebih praktis. Tapi Event Sourcing punya beberapa kelebihan yang bikin banyak developer rela pusing:
1. Audit trail lengkap – Setiap perubahan tercatat siapa, kapan, dan apa yang berubah. Cocok untuk sistem keuangan atau kesehatan yang butuh jejak transparan.
2. Mudah melacak bug – Kalau ada kesalahan, kamu bisa “memutar ulang” event-event untuk melihat di mana letak masalahnya. Mirip kayak menonton rekaman CCTV.
3. Fleksibel untuk analisis – Ingin tahu pola pembelian pelanggan dalam 3 bulan terakhir? Tinggal ambil semua event yang relevan dan analisis. Nggak perlu query rumit.
4. Mendukung sistem masa lalu – Kalau nanti mau bikin fitur baru yang butuh data historis, kamu punya semua datanya. Tinggal rekonstruksi state dari event-event.
Tapi Ada Tantangannya
Event Sourcing nggak cocok untuk semua situasi. Beberapa tantangan yang perlu diperhatikan:
– Penyimpanan membesar – Karena menyimpan semua event, ukuran database bisa membesar dengan cepat. Kalau aplikasi kamu punya jutaan transaksi per hari, perlu strategi kompresi atau snapshot.
– Kompleksitas query – Untuk mendapatkan kondisi terkini, kita harus “memutar” semua event dari awal. Makanya sering dikombinasikan dengan snapshot (menyimpan state terakhir secara periodik) agar lebih cepat.
– Perubahan skema event – Kalau di tengah jalan kita mengubah format event, harus ada mekanisme migrasi. Ini bisa jadi rumit jika tidak direncanakan.
Contoh Nyata Sederhana
Coba bayangkan aplikasi catatan sederhana. Dengan pendekatan biasa, kita simpan judul, isi, dan tanggal update terakhir. Tapi dengan Event Sourcing:
– Event: `CatatanDibuat (id, judul, isi, waktu)`
– Event: `CatatanDiubah (id, judul_baru, isi_baru, waktu)`
– Event: `CatatanDihapus (id, waktu)`
Kalau pengguna ingin melihat riwayat revisi, tinggal ambil semua event berdasarkan id catatan. Kalau ada bug yang menghapus catatan secara tidak sengaja, kita bisa memutar ulang event hingga sebelum event penghapusan, lalu memulihkan data.
Kenalan dengan Istilah “CQRS”
Seringkali Event Sourcing digunakan bersama pola CQRS (Command Query Responsibility Segregation). Intinya, kita pisahkan jalur untuk menulis data (command) dan membaca data (query). Karena dengan Event Sourcing, membaca data dari event bisa lambat, maka kita buat database read model terpisah yang diupdate secara real-time dari event. Jadi command menulis event ke event store, sementara query langsung baca dari read model yang sudah siap pakai.
Kesimpulan
Event Sourcing adalah konsep yang powerful untuk aplikasi yang membutuhkan audit trail, kemampuan rollback, dan analisis historis. Tapi bukan berarti harus dipakai di semua proyek. Untuk aplikasi sederhana seperti blog pribadi, mungkin terlalu berlebihan. Tapi untuk sistem perbankan, e-commerce besar, atau aplikasi kesehatan, Event Sourcing bisa jadi penyelamat.
Jadi, kalau suatu saat kamu mendengar istilah “kami menyimpan semua event, bukan state terakhir”, sekarang kamu sudah tahu maksudnya. Siapa tahu, mungkin suatu hari nanti kamu juga akan menerapkannya di proyekmu sendiri. Selamat mencoba!