Event Streaming #

Dalam sistem modern yang berskala besar, data tidak lagi bersifat statis. Data terus mengalir: user melakukan klik, transaksi terjadi, sensor mengirimkan sinyal, service saling berkomunikasi, dan log terus dihasilkan. Untuk menangani aliran data yang real-time, masif, dan berkelanjutan, lahirlah sebuah paradigma bernama Event Streaming.

Artikel ini akan membahas secara mendalam:

1. Apa itu Event Streaming
2. Konsep dasar event dan stream
3. Arsitektur Event Streaming
4. Komponen utama dalam Event Streaming Platform
5. Perbedaan Event Streaming dengan Message Queue
6. Use case nyata di industri
7. Tantangan dan best practice

Apa Itu Event Streaming? #

Event Streaming adalah paradigma arsitektur di mana event (kejadian) diproduksi, disimpan, diproses, dan dikonsumsi secara berkelanjutan (streaming) oleh satu atau banyak sistem.

Event adalah fakta bahwa sesuatu telah terjadi pada satu titik waktu.

Contoh event:

• User melakukan login
• Order berhasil dibuat
• Pembayaran gagal
• Sensor IoT mengirimkan suhu
• Service A mengubah status data

Event streaming memungkinkan sistem untuk:

• Merespons event secara real-time
• Menyimpan histori event
• Memproses data secara asinkron
• Mendukung banyak consumer tanpa coupling ketat

Event vs Data Tradisional #

Dalam database:

“Status user sekarang adalah ACTIVE”

Dalam event streaming:

“User X diaktifkan pada jam 10:31”

Event streaming tidak fokus pada state akhir, tetapi perjalanan perubahan state.

Konsep Dasar Event Streaming #

Event #

Event biasanya bersifat:

• Immutable (tidak diubah)
• Append-only
• Memiliki timestamp
• Mengandung payload (data)

Contoh struktur event:

{
  "event_id": "uuid",
  "event_type": "order_created",
  "timestamp": "2026-01-22T10:31:00Z",
  "data": {
    "order_id": 123,
    "user_id": 456,
    "amount": 250000
  }
}

Stream #

Stream adalah urutan event yang terurut berdasarkan waktu.

Contoh:

• user-events
• order-events
• payment-events

Stream bersifat:

• Infinite
• Ordered
• Durable (disimpan dalam jangka waktu tertentu)

Producer dan Consumer #

• Producer: sistem yang menghasilkan event
• Consumer: sistem yang membaca dan memproses event

Satu producer bisa memiliki banyak consumer, dan sebaliknya.

Arsitektur Event Streaming #

Secara umum:

[ Producer ]
     |
     v
[ Event Streaming Platform ]
     |
     +--> Consumer A
     +--> Consumer B
     +--> Consumer C

Karakteristik utama: #

• Producer tidak tahu siapa consumer
• Consumer bebas membaca ulang event
• Sistem menjadi loosely coupled
• Skalabilitas tinggi

Komponen Utama Event Streaming Platform #

Broker / Log Storage #

Tempat event disimpan dalam bentuk log terdistribusi.

Contoh:

• Apache Kafka
• Apache Pulsar
• Redpanda
• AWS Kinesis
• Google Pub/Sub (dengan konsep streaming)

Topic / Stream #

Logical channel tempat event dikirim.

Contoh:

topic: order-events
partition: 0,1,2

Partition memungkinkan:

• Parallel processing
• High throughput

Offset #

Offset adalah posisi consumer dalam stream.

Keunggulan besar event streaming:

• Consumer mengontrol offset
• Bisa replay event
• Bisa reprocess data lama

Event Streaming vs Message Queue #

Ini bagian yang sering disalahpahami.

Message Queue cocok untuk:

• Background job
• Task processing

Event Streaming cocok untuk:

• Data pipeline
• Real-time analytics
• Event-driven architecture

Use Case Event Streaming di Dunia Nyata #

Microservices Communication #

Alih-alih service saling call secara langsung:

• Service A publish event
• Service B, C, D subscribe

➡ Mengurangi tight coupling

Real-Time Analytics #

• Clickstream analysis
• Fraud detection
• Monitoring user behavior

Event Sourcing #

State aplikasi dibangun dari event, bukan database mutable.

Keuntungan:

• Full audit log
• Time travel
• Debugging lebih mudah

Data Integration & CDC #

• Sinkronisasi database
• Change Data Capture
• Integrasi antar sistem legacy

Tantangan Event Streaming #

Event Versioning #

Schema event bisa berubah. Solusi:

• Schema Registry
• Backward compatibility

Ordering #

Ordering hanya dijamin dalam satu partition. Perlu desain key yang tepat.

Exactly-Once Semantics #

Sulit dan mahal. Seringkali at-least-once + idempotency lebih realistis.

Observability #

Event-driven system sulit ditrace. Perlu:

• Correlation ID
• Distributed tracing

Best Practice Event Streaming #

• Anggap event sebagai kontrak publik
• Jangan publish event internal sembarangan
• Desain event berbasis fakta, bukan command
• Buat consumer idempotent
• Jangan mengandalkan consumer tunggal
• Pisahkan event domain dan event integration

Penutup #

Event Streaming bukan sekadar teknologi seperti Kafka atau Pub/Sub, tetapi cara berpikir baru dalam membangun sistem.

Dari sistem yang berbasis request-response ke sistem yang berbasis alur kejadian (flow of events)

Dalam skala besar dan sistem modern:

• Event streaming meningkatkan skalabilitas
• Mengurangi coupling
• Membuka pintu untuk real-time processing dan data-driven architecture

Namun, kompleksitasnya juga meningkat, sehingga desain yang matang dan discipline engineering menjadi kunci.