Event-Driven Architecture: Fondasi Sistem Real-Time

Banyak sistem enterprise bekerja dengan pola yang sederhana.

Aplikasi A membutuhkan informasi dari aplikasi B. Aplikasi A mengirim request. Aplikasi B memprosesnya. Aplikasi A menunggu response sebelum melanjutkan proses berikutnya.

Pola tersebut dikenal sebagai request-response dan masih sangat tepat untuk banyak kebutuhan.

Masalah mulai muncul ketika perusahaan memiliki banyak sistem dan perubahan harus diketahui oleh banyak aplikasi secara cepat.

Bayangkan sebuah order baru dibuat.

Informasi tersebut mungkin perlu diketahui oleh:

• Sistem inventori.
• Warehouse.
• Finance.
• CRM.
• Loyalty system.
• Notification service.
• Analytics.
• Fraud detection.
• AI agent.

Jika setiap sistem harus terus menerus bertanya:

“Apakah ada order baru?”

arsitektur menjadi semakin penuh dependency dan request yang sebenarnya tidak diperlukan.

Pendekatan lain adalah membuat sistem mengumumkan:

“Order baru telah dibuat.”

Aplikasi yang membutuhkan informasi tersebut dapat bereaksi secara independen.

Inilah prinsip utama Event-Driven Architecture.

Microsoft mendefinisikan event-driven architecture sebagai pola di mana event producer menghasilkan event, event consumer merespons event tersebut, dan event channel atau broker menjadi penghubung di antara keduanya. Producer dan consumer tidak perlu saling mengetahui secara langsung. (Microsoft Azure Architecture Center)

Dengan kata lain:

Sistem real-time bukan sistem yang terus bertanya apakah sesuatu berubah. Sistem seharusnya mengetahui ketika perubahan terjadi.

Apa yang Dimaksud Event?

Event adalah fakta bahwa sesuatu telah terjadi.

Contohnya:

• OrderCreated
• PaymentConfirmed
• StockUpdated
• CustomerRegistered
• DocumentUploaded
• ShipmentDelivered
• MachineTemperatureChanged

Perhatikan penggunaan bentuk lampau.

Event bukan perintah.

CreateOrder merupakan command.

OrderCreated merupakan event.

Perbedaannya penting.

Command mengatakan:

“Lakukan sesuatu.”

Event mengatakan:

“Sesuatu sudah terjadi.”

Setelah sebuah event diterbitkan, producer tidak harus mengetahui siapa yang akan menggunakannya.

Misalnya sistem order menerbitkan OrderCreated.

Warehouse dapat mulai menyiapkan barang.

CRM memperbarui aktivitas pelanggan.

Analytics mencatat transaksi.

Notification service mengirim konfirmasi.

Fraud detection melakukan pemeriksaan.

Sistem order tidak harus memanggil kelima layanan tersebut satu per satu.

Request-Response vs Event-Driven

Keduanya bukan pilihan yang saling menggantikan.

Sistem enterprise biasanya menggunakan kombinasi keduanya.

Contohnya, ketika pengguna membuka halaman pelanggan:

GET /customers/123

request-response sangat tepat karena aplikasi membutuhkan jawaban saat itu juga.

Namun ketika pelanggan memperbarui alamat, sistem dapat menerbitkan:

CustomerAddressUpdated

Event tersebut kemudian digunakan billing, delivery, CRM, atau data platform tanpa membuat aplikasi customer memanggil semuanya secara langsung.

Google Cloud menjelaskan bahwa event-driven architecture memungkinkan layanan berkomunikasi secara asynchronous melalui event sehingga producer dan consumer dapat berjalan lebih independen. (Google Cloud)

Tiga Komponen Utama

1. Event Producer

Sistem yang menghasilkan event.

Contohnya:

• ERP.
• CRM.
• Mobile application.
• IoT sensor.
• Payment system.
• Custom enterprise software.

Producer sebaiknya hanya bertanggung jawab menyatakan fakta yang memang terjadi pada domainnya.

2. Event Broker atau Channel

Event tidak selalu dikirim langsung dari producer ke consumer.

Biasanya terdapat infrastructure seperti:

• Message broker.
• Event bus.
• Queue.
• Streaming platform.

Lapisan ini menerima dan mendistribusikan event.

Contoh teknologi yang umum digunakan meliputi Kafka, RabbitMQ, Amazon EventBridge, Google Pub/Sub, atau Azure Event Grid.

Teknologi spesifik bukan keputusan pertama.

Yang lebih penting adalah memahami pola komunikasi dan jaminan delivery yang dibutuhkan.

3. Event Consumer

Consumer mendengarkan event tertentu lalu menjalankan tindakan.

Satu event dapat memiliki banyak consumer.

Producer tidak harus berubah ketika consumer baru ditambahkan.

Ini merupakan salah satu keuntungan terbesar event-driven architecture: loose coupling.

Kenapa Loose Coupling Penting?

Bayangkan order service memanggil lima sistem secara langsung:

Order → Inventory → Finance → CRM → Notification → Analytics

Jika salah satu sistem lambat atau down, proses order dapat ikut terhambat.

Selain itu, order service harus mengetahui API dan dependency seluruh sistem tersebut.

Ketika perusahaan menambahkan loyalty service baru, order service harus diubah lagi.

Dalam event-driven architecture:

Order Service → OrderCreated Event

Kemudian:

Inventory ← Event
Finance ← Event
CRM ← Event
Notification ← Event
Analytics ← Event

Order service hanya mengetahui event yang diterbitkan.

AWS menjelaskan bahwa EDA menggunakan layanan yang decoupled sehingga producer dapat menerbitkan perubahan tanpa mengetahui consumer mana yang akan merespons. Pendekatan ini membantu scalability dan memungkinkan komponen berkembang secara lebih independen. (AWS)

Prinsip ini sangat relevan ketika enterprise memiliki banyak aplikasi dan integrasi.

Event-Driven Architecture Bukan Sama dengan Microservices

Event-driven architecture sering digunakan bersama microservices.

Tetapi keduanya tidak sama.

Sebuah modular monolith dapat menerbitkan event.

Legacy system juga dapat menghasilkan event melalui integration layer.

Sebaliknya, microservices dapat tetap menggunakan request-response sepenuhnya.

Jangan memecah aplikasi menjadi puluhan microservices hanya karena ingin menerapkan event-driven architecture.

Tujuannya adalah mengurangi dependency yang memang menjadi masalah, bukan menambah distributed system tanpa alasan bisnis.

Queue dan Event Streaming Bukan Hal yang Sama

Message Queue

Queue cocok ketika satu pekerjaan perlu diproses oleh salah satu worker.

Contohnya:

GenerateInvoice

Beberapa worker dapat mengambil pekerjaan dari queue, tetapi satu pesan biasanya diproses oleh satu consumer.

Queue berguna untuk:

• Background processing.
• Job distribution.
• Buffer workload.
• Retry.

Event Streaming

Pada event streaming, event disimpan dalam log yang dapat dibaca beberapa consumer.

Consumer bahkan dapat membaca ulang event lama.

Microsoft menjelaskan bahwa event streaming menyediakan durable event log sehingga consumer dapat bergabung kemudian atau melakukan replay untuk recovery dan reprocessing. (Microsoft Azure Architecture Center)

Streaming relevan untuk:

• Analytics.
• Fraud detection.
• IoT.
• Activity tracking.
• Data pipeline.
• Real-time monitoring.
• High-volume transaction event.

Tidak semua sistem membutuhkan Kafka atau event streaming.

Queue sederhana sering sudah cukup.

Eventual Consistency: Trade-Off yang Harus Dipahami

Event-driven architecture biasanya asynchronous.

Artinya, setelah order dibuat, seluruh sistem mungkin tidak langsung memiliki state terbaru pada milidetik yang sama.

Contohnya:

09:00:00 — order dibuat.
09:00:01 — inventory diperbarui.
09:00:03 — CRM diperbarui.
09:00:05 — analytics menerima event.

Selama beberapa detik, data dapat berbeda.

Kondisi ini disebut eventual consistency.

Microsoft mencatat bahwa eventual consistency merupakan salah satu trade-off utama EDA karena setiap consumer memproses event dengan kecepatannya sendiri.

Karena itu, perusahaan perlu menentukan:

Data mana yang benar-benar membutuhkan strong consistency?

Saldo pembayaran mungkin membutuhkan kontrol yang jauh lebih ketat daripada update dashboard analytics.

Jangan menjadikan seluruh sistem asynchronous jika proses bisnis membutuhkan keputusan langsung dan konsisten.

Risiko yang Sering Diabaikan

Duplicate Event

Consumer dapat menerima event lebih dari sekali.

Karena itu, proses penting sebaiknya idempotent.

Jika event PaymentConfirmed diterima dua kali, sistem tidak boleh membuat dua invoice atau mengirim barang dua kali.

Event Ordering

Event dapat datang tidak sesuai urutan.

Misalnya:

OrderCancelled

tiba sebelum consumer selesai memproses:

OrderCreated.

Untuk proses tertentu, ordering perlu dirancang secara eksplisit.

Failed Consumer

Producer sudah berhasil menerbitkan event, tetapi consumer gagal memprosesnya.

Sistem membutuhkan:

• Retry.
• Dead-letter queue.
• Alert.
• Recovery procedure.

Event Schema Berubah

Event adalah contract.

Jika field dihapus atau artinya berubah, banyak consumer dapat rusak.

Versioning dan backward compatibility tetap dibutuhkan seperti pada API.

Sulit Debugging

Pada request-response, perjalanan request relatif mudah diikuti.

Dalam event-driven system, satu event dapat menghasilkan banyak event berikutnya.

Karena itu, correlation ID, distributed tracing, logging, dan observability menjadi sangat penting.

Real-Time Tidak Selalu Dibutuhkan

Salah satu kesalahan umum adalah menganggap real-time selalu lebih baik.

Padahal real-time menambah:

• Infrastructure.
• Monitoring.
• Operational complexity.
• Failure scenario.
• Cost.
• Data consistency challenge.

Laporan keuangan bulanan tidak membutuhkan event processing dalam milidetik.

Master data tertentu mungkin cukup diperbarui setiap beberapa menit.

Batch processing tetap masuk akal untuk banyak kebutuhan.

Event-driven architecture lebih relevan ketika:

• Perubahan harus segera diketahui.
• Banyak sistem perlu merespons satu kejadian.
• Volume transaksi tinggi.
• Producer tidak boleh tergantung pada consumer.
• Workload berubah secara signifikan.
• Sistem memerlukan asynchronous processing.
• Event historis memiliki nilai analitik.

Microsoft bahkan memperingatkan bahwa EDA kurang tepat ketika tim belum memiliki pengalaman mengoperasikan distributed asynchronous systems, karena debugging, monitoring, dan recovery memiliki karakter berbeda dari arsitektur synchronous.

Event-Driven Architecture dan AI Agent

EDA menjadi menarik ketika AI agent mulai masuk ke workflow operasional.

Contohnya:

LargeOrderCreated

Event tersebut dapat memicu AI agent untuk:

1. Mengumpulkan histori pelanggan.
2. Memeriksa pola transaksi.
3. Membaca aturan perusahaan.
4. Membuat risk summary.
5. Mengirim rekomendasi kepada approver.

Atau:

MachineAnomalyDetected

dapat memicu agent untuk:

1. Membaca sensor history.
2. Membandingkan maintenance record.
3. Membuka maintenance ticket.
4. Memberikan rekomendasi kepada engineer.

AWS bahkan menempatkan event-driven architecture sebagai salah satu fondasi penting untuk serverless AI karena event dapat menjadi trigger bagi layanan atau agent tanpa menciptakan tight coupling. (AWS Prescriptive Guidance)

Namun, agent sebaiknya tidak selalu langsung melakukan tindakan kritis.

Event dapat memicu analisis AI, sementara transaksi sensitif tetap menggunakan workflow deterministik dan approval.

Event-Driven Architecture dan API-First

API dan event bekerja sangat baik bersama.

Gunakan API ketika sistem membutuhkan sesuatu.

Gunakan event ketika sistem ingin mengumumkan sesuatu.

Contohnya:

Customer service menggunakan API:

GET /orders/123

untuk mengetahui status order saat ini.

Ketika status berubah, order service menerbitkan:

OrderStatusChanged

agar sistem lain dapat merespons.

Karena itu, enterprise architecture yang matang biasanya bukan:

API atau event?

Melainkan:

Interaksi mana yang harus synchronous dan mana yang lebih tepat asynchronous?

Checklist Kesiapan Event-Driven Architecture

Kesimpulan

Event-Driven Architecture membantu perusahaan membangun sistem yang merespons perubahan tanpa menciptakan dependency langsung antara setiap aplikasi.

Producer mengumumkan event.

Consumer memilih event yang relevan.

Message broker atau event stream menghubungkan keduanya.

Hasilnya adalah arsitektur yang lebih fleksibel untuk integration, high-volume processing, automation, IoT, analytics, dan AI.

Namun, event-driven architecture bukan solusi universal.

Perusahaan harus siap mengelola duplicate event, ordering, retry, schema evolution, observability, dan eventual consistency.

Sistem terbaik biasanya menggabungkan beberapa pola.

Request-response digunakan ketika jawaban dibutuhkan langsung.

Queue digunakan untuk pekerjaan asynchronous.

Event streaming digunakan ketika banyak consumer membutuhkan histori event.

Perspektif yang lebih tepat bukan:

“Bagaimana membuat seluruh sistem real-time?”

Melainkan:

“Perubahan bisnis apa yang cukup penting sehingga sistem lain perlu mengetahuinya saat perubahan itu terjadi?”

Bangun Sistem yang Lebih Responsif Bersama Crocodic

Crocodic membantu perusahaan merancang sistem enterprise yang dapat beradaptasi dengan pertumbuhan transaksi, integrasi, automation, dan kebutuhan real-time.

Melalui layanan Enterprise System Upgrade, sistem yang sudah berjalan dapat diperkuat melalui API integration, asynchronous processing, automation, scalability, dan integration layer tanpa selalu dibangun ulang dari awal.

Untuk kebutuhan sistem baru, Custom Enterprise Software memungkinkan arsitektur dibentuk sesuai workflow, volume transaksi, data, role pengguna, dan kebutuhan integration perusahaan.

Event-driven architecture dapat menjadi bagian dari fondasi tersebut ketika perubahan bisnis perlu diketahui banyak sistem secara cepat tanpa menciptakan ketergantungan point-to-point.

Tujuannya bukan membuat arsitektur paling kompleks.

Tujuannya adalah membuat sistem dapat merespons perubahan bisnis dengan cara yang tetap dapat dikembangkan dan dikendalikan.

Diskusikan arsitektur integrasi dan kebutuhan real-time system perusahaan Anda bersama Crocodic.