Event-Driven Architecture #

Dalam beberapa tahun terakhir, istilah Event-Driven Architecture (EDA) semakin sering muncul dalam diskusi arsitektur sistem modern. Mulai dari microservices, real-time system, hingga platform skala besar seperti e-commerce, fintech, dan streaming service — EDA menjadi salah satu pendekatan utama untuk membangun sistem yang scalable, decoupled, dan resilient.

Namun, apa sebenarnya Event-Driven Architecture? Mengapa banyak perusahaan besar mengadopsinya? Dan apa konsekuensi teknis yang perlu dipahami engineer sebelum menggunakannya?

Artikel ini akan membahas EDA secara mendalam dan sistematis.

Apa Itu Event-Driven Architecture? #

Event-Driven Architecture adalah pendekatan arsitektur di mana alur komunikasi antar komponen sistem didorong oleh event, bukan oleh pemanggilan langsung (request-response).

Definisi Singkat #

Event adalah fakta bahwa sesuatu telah terjadi di dalam sistem.

Contoh event:

• UserRegistered
• OrderCreated
• PaymentCompleted
• EmailSent
• InventoryUpdated

Dalam EDA:

• Sebuah producer mempublikasikan event
• Satu atau lebih consumer mendengarkan event tersebut
• Producer tidak tahu siapa yang mengonsumsi event-nya

Ini menciptakan loose coupling secara alami.

Perbedaan Fundamental dengan Request-Response Architecture #

Contoh request-response:

Order Service -> Payment Service -> Email Service

Contoh event-driven:

Order Service -> publish OrderCreated
Payment Service <- subscribe OrderCreated
Email Service   <- subscribe OrderCreated
Analytics       <- subscribe OrderCreated

Komponen Utama Event-Driven Architecture #

Event Producer #

Komponen yang:

• Menghasilkan event
• Tidak peduli siapa yang mendengarkan
• Hanya bertanggung jawab pada domain-nya sendiri

Contoh:

• Order Service mem-publish OrderCreated
• User Service mem-publish UserRegistered

Event Consumer #

Komponen yang:

• Mendengarkan event tertentu
• Menjalankan logic berdasarkan event
• Bisa lebih dari satu untuk event yang sama

Contoh:

• Email Service
• Notification Service
• Fraud Detection
• Audit / Logging

Event Broker / Message Broker #

Perantara yang mengelola:

• Delivery event
• Buffering
• Retry
• Ordering (opsional)

Contoh teknologi:

• Apache Kafka
• RabbitMQ
• AWS SNS/SQS
• Google Pub/Sub
• Azure Event Hub

Broker adalah jantung EDA.

Event Schema & Contract #

Event bukan sekadar JSON, tetapi kontrak antar service.

Contoh:

{
  "event_id": "uuid",
  "event_type": "OrderCreated",
  "occurred_at": "2026-01-22T10:00:00Z",
  "payload": {
    "order_id": "123",
    "user_id": "456",
    "amount": 250000
  }
}

Perubahan schema event adalah breaking change dan harus dikelola dengan sangat hati-hati.

Kenapa Event-Driven Architecture Dibutuhkan? #

Mengatasi Tight Coupling #

Tanpa EDA:

• Satu service down → chain failure
• Sulit menambah fitur baru

Dengan EDA:

• Producer tetap jalan walau consumer gagal
• Consumer bisa ditambah tanpa mengubah producer

Skalabilitas Horizontal #

Event bisa:

• Diproses paralel
• Dibagi ke banyak consumer
• Diskalakan independen

Ini sangat cocok untuk:

• High traffic system
• Burst traffic (flash sale, campaign)

Resilience & Fault Isolation #

Jika Email Service gagal:

• Order tetap tercatat
• Payment tetap diproses
• Email bisa retry belakangan

EDA menghindari single point of failure.

Mendukung Asynchronous Workflow #

Banyak proses bisnis tidak harus sinkron:

• Kirim email
• Update analytics
• Sync ke third-party
• Audit log

EDA membuat workflow seperti ini natural dan eksplisit.

Pola Umum dalam Event-Driven Architecture #

Publish-Subscribe #

Satu event → banyak consumer Pola paling umum.

Event Notification vs Event-Carried State Transfer #

Event Notification

• Event hanya sinyal
• Consumer fetch data sendiri

Event-Carried State Transfer

• Event membawa data lengkap
• Consumer tidak perlu query ulang

Pilihan ini mempengaruhi:

• Coupling data
• Konsistensi
• Payload size

Eventual Consistency #

EDA hampir selalu mengarah ke:

• Eventual consistency
• Bukan strong consistency

Engineer harus:

• Menerima data tidak langsung konsisten
• Mendesain UX dan business rule dengan sadar

Tantangan dan Trade-Off Event-Driven Architecture #

Debugging Lebih Sulit #

• Alur tidak linear
• Tracing lintas service
• Perlu distributed tracing (OpenTelemetry)

Data Duplication #

• Setiap service punya data sendiri
• Event bisa membawa snapshot data

Ini bukan bug, tapi konsekuensi desain.

Idempotency #

Consumer harus aman menerima event yang sama lebih dari sekali.

Tanpa idempotency:

• Double email
• Double payment
• Double notification

Event Versioning #

Event tidak bisa diubah sembarangan. Solusi umum:

• Versioned event (OrderCreated.v1)
• Backward-compatible schema

Kapan Event-Driven Architecture Cocok Digunakan? #

Cocok jika: #

• Sistem besar & berkembang
• Banyak side-effect
• Perlu scaling independen
• Workflow kompleks
• Banyak integrasi

Tidak cocok jika: #

• Aplikasi CRUD sederhana
• Tim kecil tanpa observability
• Kebutuhan strong consistency
• Overhead tidak sebanding

Event-Driven Architecture dan Microservices #

EDA bukan syarat microservices, tapi:

• Microservices tanpa EDA → sering jadi distributed monolith
• EDA membantu microservices menjadi benar-benar decoupled

Namun:

EDA menambah kompleksitas arsitektur, bukan menguranginya.

Penutup #

Event-Driven Architecture adalah:

• Paradigma arsitektur yang powerful
• Cocok untuk sistem modern dan skala besar
• Membawa scalability, resilience, dan flexibility

Namun:

• Membutuhkan kedewasaan engineering
• Observability, schema governance, dan discipline adalah kunci

EDA bukan silver bullet, tetapi jika digunakan dengan benar, ia menjadi fondasi yang sangat kuat untuk sistem jangka panjang.