Peralihan dari Data Relasional ke Event

Panduan Peralihan dari Data Relasional ke Event

• Dalam aliran event sourcing, data bisnis tidak hilang, melainkan disimpan dalam bentuk event.
• Event merepresentasikan fakta yang telah terjadi, dan disimpan setelah setiap tindakan.
• Event stream adalah daftar semua event yang tercatat, bersifat immutable, dan kesalahan di masa lalu dapat diperbaiki dengan menambahkan event baru.

1. Cari kolom status

• Nilai pada kolom status dapat mencerminkan tahap siklus hidup data.
• Misalnya, pesanan bisa dimulai, dikirim, dan dibayar.
• Status-status ini dapat diubah menjadi event seperti Order Initiated, Order Shipped, dan Order Paid.

2. Periksa kolom tanggal

• Kolom tanggal dapat memberikan informasi tentang kejadian-kejadian penting dalam suatu proses.
• ShipmentDate, DeliveryDate, OrderPlacementDate, dan sejenisnya dapat menunjukkan istilah bisnis serta membantu memperkenalkan event baru.

3. Analisis selektivitas kolom

• Kolom nullable mungkin diberikan belakangan atau bersifat opsional.
• Kolom wajib harus disediakan pada event Order Initiated pertama.

4. Cari tabel dengan relasi 1 ke banyak terbanyak

• Dalam event sourcing, data dikelompokkan berdasarkan proses bisnis untuk pemrosesan yang efisien.
• Tabel dengan banyak relasi 1 ke banyak dapat menjadi kandidat untuk jenis stream.

5. Perkenalkan event secara eksplisit

• Saat memigrasikan data relasional ke event, event yang baru ditemukan sebaiknya tidak digunakan ulang selama impor; sebagai gantinya, event Order Imported harus disediakan secara eksplisit.

6. Bereksperimen dan memverifikasi

• Cobalah prototipe di lingkungan yang aman, bandingkan hasilnya dengan ekspektasi, dan lakukan iterasi tanpa terburu-buru.

Pendapat GN⁺

• Hal terpenting dalam tulisan ini adalah pentingnya pendekatan baru yang mempertahankan data bisnis saat beralih dari database relasional ke event sourcing.
• Tulisan ini menarik karena menawarkan cara untuk lebih memahami dan memanfaatkan siklus hidup data, keluar dari pendekatan pengelolaan data yang lama.
• Event sourcing dapat membantu membangun pemahaman bersama antara tim bisnis dan tim teknis, bukan hanya dari sudut pandang teknis.

[GN⁺]

Komentar Hacker News

• Merekomendasikan penggunaan PostgreSQL dan alat pelaporan FOSS

  • Jika aplikasi sudah menggunakan PostgreSQL, disarankan menyimpan data event di PostgreSQL dan menggunakan alat pelaporan FOSS (Apache Superset, Metabase, dan sebagainya).
  • PostgreSQL digunakan sampai data mencapai sekitar 2TB, lalu setelah itu diputuskan apakah 2TB data tersebut memang perlu tetap online, atau cukup ringkasan harian/per jam saja.
  • Dalam satu kasus klien, sistem menangani lebih dari 10TB data dan 1500 event per detik; data terperinci disimpan online selama 2 hari, sisanya diringkas dan dipindahkan ke S3 agar bisa di-query melalui Athena SQL.
  • Menggunakan AWS RDS Multi-AZ untuk mendukung failover otomatis, dan satu engineer merawat semuanya dengan kurang dari 5 jam per bulan.
  • PostgreSQL menyediakan satu sistem tunggal untuk menyimpan, mempelajari, mengelola, dan menskalakan data di satu tempat.
  • Staf nonteknis pun dapat dengan mudah membuat grafik di sistem seperti Metabase atau Preset.
  • PostgreSQL terus berkembang setiap tahun, dan bila diperlukan, penskalaan tambahan dimungkinkan melalui sistem yang kompatibel dengan PostgreSQL (Aurora, TimescaleDB, CitusDB, dan sebagainya).

• Kapan arsitektur event-driven tepat digunakan

  • Jika pelanggan melakukan tindakan tertentu dan mengharapkan respons, itu adalah pola request/response, bukan event-driven.
  • Event-driven berarti sesuatu terjadi dalam situasi yang tidak terduga. Contohnya, saat kode didorong ke GitHub lalu build terpicu.

• Berbagi pengalaman skeptis terhadap event sourcing

  • Satu tim sempat mempertimbangkan event sourcing, tetapi akhirnya memutuskan untuk tidak menggunakannya karena tidak melihat manfaat yang jelas dan menganggap risiko mencoba hal baru terlalu besar.
  • Tidak ada penyesalan karena melewatkan kesempatan belajar, dan keputusan untuk tidak terjun ke masalah kompleks saat memang tidak diperlukan dinilai positif.

• Kegunaan pemodelan domain event

  • Pemodelan domain event berguna untuk berkomunikasi dengan para ahli domain yang ingin diajak menyelesaikan masalah.
  • Saat mengimplementasikan sistem yang menyediakan jejak audit untuk state machine jangka panjang, lebih baik menggunakan alat seperti Temporal.io/durable functions.
  • Alat-alat tersebut menggunakan event sourcing secara internal, sekaligus memaksa penulisan kode dengan mempertimbangkan deduplikasi dan idempotensi.

• Pertanyaan tentang implementasi event sourcing

  • Masih kurang penjelasan tentang cara merekonstruksi state saat ini secara efisien dari event stream dan bagaimana memodelkan event stream di database.

• Bottom-up vs top-down, kustom vs general-purpose

  • Pendekatan top-down dimulai dari domain bisnis lalu memetakan implementasi ke teknologi, alat, dan vendor yang tersedia.
  • Pendekatan bottom-up dimulai dari teknologi, alat, dan vendor yang tersedia lalu merangkai solusi yang berfungsi.
  • Pendekatan kustom mencakup DDD, CQRS/ES, Sagas, TBUI, GraphQL, algebraic data types, dan sebagainya.
  • Pendekatan general-purpose mencakup RDBMS, CRUD, REST, transaksi ACID, CDC, UI administrasi umum, no-code/low-code, tipe terbatas/umum, dan sebagainya.

• Dukungan dan kritik terhadap arsitektur berbasis event

  • Ada dukungan terhadap arsitektur berbasis event, tetapi artikel tersebut gagal menyampaikan argumennya dengan jelas.
  • Jika fokus diarahkan pada perbedaan antara relasi data dan perilaku bisnis, menjadi lebih jelas mengapa perlu menjauh dari penyimpanan data relasional operasional.

• Event sourcing dan kebutuhan akan relasi

  • Terlepas dari banyak kelebihan event sourcing, relasi tetap dibutuhkan.
  • Jika seluruh relasi hanya tersirat di kode lapisan aplikasi, hal itu tidak dapat diterima.
  • Diperlukan cara untuk melakukan query atas relasi atau menjaga agar tampilan relasional tetap mutakhir.

• Dukungan terhadap data relasional

  • Diputuskan untuk menghindari kompleksitas dan tetap setia pada data relasional tradisional.

• Pemahaman baru tentang desain event-driven

  • Baru-baru ini mengenal desain event-driven, dan saat mempertimbangkan struktur data yang optimal di dunia yang didominasi AI, sampai pada kesimpulan serupa.
  • Jika desain event-driven dapat membantu mengelola kompleksitas dan benar-benar membuat data bisa dimanfaatkan, maka pendekatan itu dinilai berharga.
  • Dalam beberapa tahun ke depan, ketika AI dapat memiliki pengetahuan dan kemampuan query atas semua event bisnis, desain event-driven diperkirakan akan menjadi umum.