Belajar Data Architect - Streaming & Event-Driven Data

#Pendahuluan

Setelah di episode 6 kita merancang pipeline batch yang sehat, sekarang kita masuk ke mode kedua: streaming. Tidak semua data perlu real-time, tapi ketika kebutuhan itu ada — fraud detection, monitoring IoT, rekomendasi personal, atau sinkronisasi antar sistem — arsitek harus merancangnya dengan benar.

Mengapa episode ini penting? Karena streaming adalah salah satu area paling mudah salah desain: orang sering membangun arsitektur real-time untuk kebutuhan yang sebenarnya batch, atau membangun batch di atas fondasi yang seharusnya event-driven. Memahami kapan dan bagaimana memakai streaming membedakan arsitek yang berpikir matang dari yang sekadar mengikuti hype.

#Event Streaming dan Apache Kafka

Apache Kafka adalah platform event streaming paling dominan. Model mentalnya sederhana: append-only log. Producer menulis event ke topik, consumer membaca dengan offset sendiri — sehingga banyak consumer bisa membaca topik yang sama tanpa saling mengganggu.

Producer --> [topik: order-events] --> Consumer A (real-time fraud check)
                              \----> Consumer B (update data warehouse)
                              \----> Consumer C (feature store)

Keunggulan utama untuk arsitek:

Contoh CLI Kafka untuk praktik:

kafka-topics.sh --bootstrap-server localhost:9092 --create \
  --topic order-events --partitions 6 --replication-factor 3
 
kafka-console-producer.sh --bootstrap-server localhost:9092 \
  --topic order-events --property "key.type=int" --property "parse.key=true"

#Change Data Capture (CDC)

CDC adalah teknik menangkap perubahan pada database (INSERT, UPDATE, DELETE) dan menerbitkannya sebagai event. Ini fondasi sinkronisasi modern: alih-alih menyalin seluruh tabel berulang kali, kita hanya mengalirkan perubahan.

Tool CDC populer: Debezium (embedded di Kafka Connect), atau CDC bawaan cloud (DMS, Datastream, Fivetran). Perubahan database (sistem transaksional) diterjemahkan menjadi event dengan struktur seperti:

{
  "op": "u",
  "after": { "id": 42, "status": "shipped", "qty": 3 },
  "before": { "id": 42, "status": "paid", "qty": 3 },
  "source": { "table": "orders", "ts_ms": 1780000000000 }
}

Dengan pola ini, warehouse bisa selalu menampilkan near-real-time state, dan cache/search index bisa di-update dari event yang sama.

#Kapan Streaming Benar-Benar Dibutuhkan

Sebelum membangun platform streaming, uji kebutuhan dengan tabel sederhana:

#Arsitektur Streaming yang Andal

#1. Exactly-Once Semantics

Streaming harus menjamin tidak ada event yang hilang atau diduplikasi. Di Kafka + Flink, gunakan checkpointing dengan exactly-once — bukan at-least-once yang bisa menghasilkan duplikat saat retry.

#2. Idempotent Sink

Bahkan dengan exactly-once, desain sink idempotent sebagai lapis kedua: target table memiliki key unik, dan write memakai upsert. Ini pengaman terhadap edge case.

#3. Backpressure Handling

Jika konsumen lebih lambat dari producer, jangan menumpuk di memori — gunakan mekanisme backpressure (buffer bounded) dan monitor consumer lag. Lag yang terus naik berarti sistem perlu di-scale.

kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group order-processor
# LAG bertambah terus → konsumen kewalahan → scale out partition

#4. Schema Registry

Event adalah API antar sistem. Wajib pakai schema registry (Confluent Schema Registry / schema di message format) agar perubahan skema event dideteksi — consumer lama tidak dipecahkan oleh producer baru.

#5. Dead Letter Queue

Event yang gagal diproses jangan di-drop. Kirim ke DLQ (topik terpisah) untuk ditinjau manual. Ini beda antara "data hilang diam-diam" dan "data tertunda tapi bisa dipulihkan".

#Praktik: Streaming Pipeline CDC → Warehouse

1. Debezium: baca WAL PostgreSQL produksi → topik order-events (Kafka)
2. Flink job: validasi + enrich (join dengan dim) → topik order-enriched
3. Sink: tulis ke lakehouse (Delta) dengan upsert per business key
4. Monitoring: lag consumer, error rate, throughput → Grafana
5. DLQ: event gagal → topik order-dlq → review harian

Evaluasi: exactly-once aktif, sink idempotent, lag ter-monitor, skema ter-registry, DLQ ada. Jika kelima poin terpenuhi, pipeline streaming kalian layak produksi.

#Penutup

Inti yang harus dibawa pulang:

• Kafka = append-only log; satu event melayani banyak consumer dengan offset sendiri.
• CDC menangkap perubahan DB via log → event, cocok untuk sinkronisasi near-real-time.
• Uji kebutuhan: streaming hanya untuk keterbaruan detik-menit dengan konsumen nyata.
• Arsitektur andal = exactly-once + idempotent sink + backpressure + schema registry + DLQ.

Di episode 8 selanjutnya kita akan membahas Data Governance Framework — data catalog, lineage, metadata, dan data stewardship sebagai kerangka pengelolaan data yang akuntabel. Sampai jumpa di episode 8!