Satu Event, Banyak Sistem Bereaksi: Cara Event-Driven Architecture Menghubungkan Enterprise

Pembayaran sudah berhasil, tetapi konfirmasi pelanggan tertahan karena CRM atau analytics sedang terganggu. Jika semua API tujuan wajib berhasil, gangguan satu tujuan ikut menggagalkan alur; jika kegagalannya diabaikan, data tujuan tertinggal tanpa pemulihan yang jelas.

Dalam ilustrasi ini, Event-Driven Architecture (EDA) memungkinkan Payment menerbitkan PaymentCompleted, lalu Finance, CRM, Notification, dan Analytics merespons secara mandiri. Pembayaran tidak perlu menunggu pekerjaan analytics. Consumer baru, seperti loyalty atau fraud analytics setelah transaksi, dapat memakai kontrak yang tersedia tanpa menambah panggilan di Payment. Pemeriksaan fraud yang harus menentukan penerimaan pembayaran tetap berada pada jalur keputusan tersebut.

Apa yang Dipisahkan oleh Event?

Event menyatakan sesuatu yang sudah terjadi. Producer menghasilkan kejadian, channel menyalurkannya, dan consumer memprosesnya. Google Cloud menjelaskan pemisahan komponen ini untuk pengembangan dan ketahanan yang lebih independen.

PaymentCompleted adalah fakta; SendInvoiceEmail meminta tindakan tertentu dan merupakan command. Fowler mengingatkan agar perintah tidak disamarkan sebagai event.

Payment → PaymentCompleted → Broker
                              ├→ Finance
                              ├→ CRM
                              ├→ Notification
                              └→ Analytics

Ketergantungan tetap ada pada broker dan kontrak. Setiap consumer dapat selesai pada waktu berbeda. CONNECT mengatur pertukaran kejadian tersebut dengan pemilik dan batas keterlambatan yang jelas.

Isi Event Menentukan Ketergantungan

Dua pilihan payload memiliki konsekuensi berbeda:

Pilihan	Contoh ilustratif	Konsekuensi
Kunci saja	paymentId	Kontrak kecil, tetapi consumer memanggil API Payment untuk mengambil detail; ketersediaan Payment kembali diperlukan
Atribut yang diperlukan	paymentId, amount, currency, completedAt	Consumer dapat bekerja tanpa panggilan balik; data tersalin dan kontrak lebih besar

Martin Fowler membedakan event notification dan event-carried state transfer. Pilih berdasarkan kebutuhan consumer, bukan keinginan memasukkan seluruh record database.

Tambahkan identitas event, sumber, dan versi schema. Batasi akses subscription dan field sensitif; nomor kartu atau dokumen pribadi tidak perlu ikut dalam konfirmasi pembayaran umum. Microsoft mengingatkan bahwa event dapat terlihat oleh lebih banyak komponen daripada request langsung.

Reaksi Independen atau Proses Berurutan?

Notifikasi dan analytics dapat bereaksi tanpa saling menunggu. Sebaliknya, proses reservasi, pembayaran, dan pengiriman memiliki urutan, tenggat, serta kemungkinan kompensasi. Harus ada pihak yang mengetahui apakah proses keseluruhan selesai.

Koreografi lewat event cocok untuk alur sederhana; semakin banyak langkah, semakin sulit menelusuri status dan dependensi melingkar. Microsoft Saga membandingkannya dengan orkestrasi yang menyimpan status proses. Untuk koordinasi kompleks, lihat workflow orchestration B2.6.

Bagaimana Sistem yang Ada Menerbitkan Event?

• Kode dapat diubah: simpan perubahan bisnis dan record event dalam transaksi database yang sama melalui transactional outbox AWS. Relay mengirimnya dengan retry; duplikat tetap mungkin.
• Database dapat diakses: CDC membaca perubahan baris. Adapter perlu menerjemahkannya ke kejadian bisnis; perubahan tabel tidak otomatis berarti pembayaran selesai.
• SaaS menyediakan webhook: periksa autentikasi, retry, retensi, dan cara mengambil kejadian yang terlewat.
• Hanya ekspor atau polling tersedia: gunakan adapter terjadwal dengan deduplikasi dan rekonsiliasi. Keterlambatan mengikuti intervalnya.

Detail akses database, izin vendor, dan risiko legacy dibahas dalam Cara Modern Memperbaiki Legacy System.

Pengiriman dan Pemulihan Harus Diuji

Consumer harus idempotent: menerima PaymentCompleted dua kali tidak menghasilkan dua pencatatan. Tentukan kompatibilitas schema, retry terbatas, dead-letter handling, dan pemilik pemrosesan ulang.

Untuk streaming, tempatkan event satu entitas pada partisi yang sama bila urutannya harus dijaga. Microsoft menjelaskan bahwa pengiriman ulang setelah error dapat mengubah urutan pemrosesan. Consumer perlu memeriksa versi/urutan bisnis sebelum menerapkan event lama.

Correlation ID membantu penelusuran. Pantau backlog outbox, umur event, dan kegagalan consumer; rekonsiliasikan pembayaran dengan Finance. Pelanggan mungkin sudah menerima konfirmasi sementara CRM masih menampilkan tagihan. Tampilkan batas kesegaran; keputusan yang wajib memakai status terbaru memeriksa sistem otoritatif.

Retensi Menentukan Pilihan Channel

Pada model publish-subscribe tanpa log historis, consumer baru tidak mendapat event yang sudah lewat. Loyalty yang ditambahkan kemudian memerlukan initial load dari sistem sumber. Streaming dengan log persisten memungkinkan pemulihan, consumer terlambat, dan pemrosesan ulang setelah bug selama riwayat masih tersedia. Tetapkan masa retensi dan bootstrap sesuai kebutuhan; kemampuan aktual mengikuti produk. Penyimpanan untuk distribusi ini tidak otomatis menjadikan event sumber state aplikasi.

Mulai dari Satu Event yang Sudah Dibutuhkan

Pilih kejadian yang sekarang dikirim ke beberapa sistem melalui API atau file. Event Storming membantu menemukan makna bisnisnya. Mulai dari consumer toleran keterlambatan seperti notifikasi, sebelum pencatatan finansial kritis.

Tim producer memiliki kontrak; katalog dengan AsyncAPI membantu tim lain menemukannya. CloudEvents mendefinisikan pasangan sumber dan ID untuk identitas event, yang dapat dipakai dalam deduplikasi.

Catat baseline waktu data tiba, usaha menambah consumer, insiden karena gangguan tujuan, dan waktu rekonsiliasi manual. Bandingkan setelah pilot, selain latency dan error rate.

FAQ

Haruskah API yang ada diganti?

Tidak. Request-response sederhana tetap sesuai jika memenuhi kebutuhan. EDA tidak layak bila biaya broker tidak sebanding, konsistensi kuat lintas sistem wajib, atau tim belum siap mengoperasikan kegagalan asinkron.

Apakah EDA sama dengan Event Sourcing?

Tidak. EDA mengatur komunikasi; Event Sourcing menjadikan riwayat event sumber pembentukan state. Broker saja tidak mengubah cara aplikasi menyimpan data.

Apakah EDA selalu real-time?

Tidak. Antrean, adapter, dan pemulihan menentukan umur data. Tetapkan target per proses.

Tentukan Kontrak sebelum Memilih Broker

Sagara Xinix – Solusi Teknologi Terintegrasi dan Terpercaya menyediakan perancangan sistem dan integrasi. Bawa satu kejadian bisnis, daftar consumer, dan baseline pertukaran datanya ke diskusi dengan Sagara untuk menilai kombinasi API dan event yang sesuai.