Event-Driven Architecture dengan Kafka dan Microservices

Pukul 2 pagi di ruang server, alarm PagerDuty berteriak nyaring. Pesanan e-commerce melonjak 10 kali lipat karena flash sale, dan sistem monolitik berbasis PHP kami yang dibantu MySQL mulai megap-megap. Koneksi database jenuh, proses pembayaran timeout, dan pelanggan mengamuk. Saat itulah kami sadar, pendekatan request-response sinkron tradisional sudah mati. Kami butuh lompatan arsitektural ke Event-Driven Architecture menggunakan Apache Kafka untuk memisahkan beban antar microservices. Tapi pertanyaannya, seberapa jauh Kafka benar-benar menjadi penyelamat, dan kapan kompleksitasnya justru menjadi bumerang? Mari kita bedah dalam arena head-to-head ini.

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Ketika kita berbicara tentang arsitektur terdistribusi, perdebatan abadi selalu berputar pada bagaimana cara layanan saling menyapa. Di satu sisi, kita punya pendekatan REST/RPC sinkron yang naif—seperti menelepon seseorang dan menunggu di ujung telepon sampai mereka menjawab. Di sisi lain, kita punya Event-Driven Architecture (EDA) menggunakan Apache Kafka, di mana layanan bertindak seperti stasiun radio: mereka memancarkan event ke udara tanpa peduli siapa yang mendengarkan, dan konsumen menyetel frekuensi sesuai kebutuhan mereka.

[!IMPORTANT] Jangan pernah memperlakukan Kafka seperti message queue tradisional (seperti RabbitMQ atau SQS). Kafka adalah log terdistribusi yang immutable. Data tidak langsung dihapus setelah dibaca, melainkan disimpan berdasarkan retensi waktu atau ukuran log.

Filosofi Publisher-Subscriber di Kafka berbasis pada log compaction dan partitioning. Bayangkan sebuah pipa raksasa di mana setiap event (misal: user.created, order.paid) ditulis secara berurutan ke disk. Kunci partisi (partition key) menentukan ke shard mana sebuah event dilempar, memastikan urutan (ordering) tetap terjaga per entity kunci.

package main

import (
	"context"
	"fmt"
	"github.com/segmentio/kafka-go"
	"time"
)

func produceEvent(topic, messageKey, messageValue string) error {
	// Konfigurasi koneksi Kafka writer
	w := kafka.NewWriter(kafka.WriterConfig{
		Brokers:  []string{"localhost:9092"},
		Topic:    topic,
		Balancer: &kafka.Hash{}, // Memastikan key yang sama masuk ke partisi yang sama
	})
	defer w.Close()

	err := w.WriteMessages(context.Background(),
		kafka.Message{
			Key:   []byte(messageKey),
			Value: []byte(messageValue),
		},
	)
	if err != nil {
		return fmt.Errorf("gagal mengirim event: %w", err)
	}
	return nil
}

Memahami filosofi ini saja belum cukup untuk menyelamatkan kita dari pusingnya konfigurasi harian, terutama ketika berhadapan langsung dengan editor teks dan file konfigurasi YAML berbaris-baris.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Bekerja dengan Kafka di lingkungan production menuntut ketelitian tingkat dewa. Berbeda dengan framework web yang menyediakan scaffolding instan, setup Kafka cluster (bahkan dengan Docker Compose untuk development lokal) membutuhkan pemahaman mendalam tentang port binding, advertised listeners, dan manajemen ZooKeeper (atau KRaft mode baru).

version: '3.8'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:7.3.0
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
  kafka:
    image: confluentinc/cp-kafka:7.3.0
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: 'zookeeper:2181'
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092,PLAINTEXT_HOST://localhost:29092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

[!WARNING] Kesalahan paling fatal bagi developer pemula adalah salah konfigurasi KAFKA_ADVERTISED_LISTENERS. Jika Anda mengakses Kafka dari luar container Docker tetapi menggunakan hostname internal, consumer Anda akan mengalami timeout tanpa pesan error yang jelas.

Dari sisi penulisan kode konsumen (consumer), pengelolaan offset adalah momok tersendiri. Apakah kita menggunakan auto-commit atau manual commit? Di sinilah jam terbang insinyur diuji. Jika salah konfigurasi, Anda bisa mengalami duplicate processing atau message loss yang merusak integritas data finansial.

3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Ketika pengujian beban menggunakan k6 atau wrk digeber hingga 50.000 request per detik, di sinilah karakteristik asli arsitektur terlihat. Layanan backend berbasis Go yang terhubung ke Kafka menunjukkan ketahanan luar biasa karena sifat Kafka yang menulis ke disk secara sekuensial (sequential I/O).

Di arena pengujian, CPU server tetap stabil di bawah 40%, dan RAM tidak mengalami lonjakan ekstrem berkat mekanisme Page Cache Linux. Berbeda halnya dengan message broker berbasis memori murni yang langsung kolaps begitu antrean RAM melebihi kapasitas fisik server.

Namun, tantangan terbesar muncul ketika salah satu microservice konsumen mengalami crash saat memproses payload JSON yang korup. Pesan tersebut gagal diproses berulang-ulang, menyebabkan infinite retry loop yang memblokir partisi Kafka. Di sinilah peran krusial dari penanganan Dead Letter Queue (DLQ).

func processMessageWithDLQ(ctx context.Context, msg kafka.Message, dlqWriter *kafka.Writer) error {
	var payload OrderPayload
	err := json.Unmarshal(msg.Value, &payload)
	if err != nil {
		// Kirim ke Dead Letter Queue jika payload tidak valid
		errDLQ := dlqWriter.WriteMessages(ctx, kafka.Message{
			Key:   msg.Key,
			Value: msg.Value,
			Headers: []kafka.Header{
				{Key: "error.reason", Value: []byte(err.Error())},
			},
		})
		return errDLQ // Loloskan pesan asli agar offset bisa di-commit
	}
	
	// Proses bisnis normal...
	return nil
}

Dengan mengarahkan pesan beracun (poison pill) ke DLQ, sistem tetap berjalan lancar tanpa menghentikan aliran data untuk ribuan pengguna lainnya. Dari sinilah kita mulai menghitung efisiensi biaya infrastruktur yang digunakan.

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Infrastruktur skala besar selalu bermuara pada satu hal: lembar tagihan AWS atau dedicated server bulanan. Kafka dikenal rakus akan disk space jika retensi data diset terlalu lama. Namun, dari sisi memori RAM, Kafka sangat efisien karena mendelegasikan caching data ke OS Page Cache.

Dalam perbandingan biaya operasional bulanan untuk menangani 100 juta event per hari:

• Monolitik / Database Polling Tradisional: Membutuhkan instance database berkapasitas tinggi (RAM besar, SSD NVMe mahal) untuk menghindari locking table.
• Kafka Event-Driven Cluster: Cukup menggunakan 3 node broker berukuran sedang dengan storage HDD/SSD standar (karena operasi tulis sekuensial tidak menuntut IOPS ekstrem).

Secara jangka panjang, investasi waktu untuk menguasai Kafka terbayar lunas melalui penghematan kapasitas instance cloud yang drastis, asalkan arsitekturnya dirancang sejak awal untuk menangani partisi dengan bijak.

5. Kapan Wajib Menggunakan Apache Kafka

Jangan gunakan Kafka hanya karena ingin mengikuti tren arsitektur terkini. Gunakan Apache Kafka jika dan hanya jika:

1. Sistem Anda melayani jutaan event lintas layanan dan membutuhkan real-time stream processing.
2. Anda memerlukan kemampuan event sourcing di mana setiap perubahan state aplikasi harus tercatat sebagai audit trail yang tidak boleh diubah.
3. Tim Anda memiliki kapasitas operasional untuk memelihara cluster terdistribusi dan memahami konsep partisi serta replikasi secara mendalam.

6. Kapan Wajib Menggunakan Arsitektur Sinkron Tradisional

Sebaliknya, tinggalkan Kafka dan pilih pendekatan tradisional (REST API langsung atau message queue ringan seperti Redis/RabbitMQ) jika:

1. Aplikasi Anda masih berupa MVP (Minimum Viable Product) dengan jumlah pengguna harian di bawah ribuan.
2. Kompleksitas domain bisnis rendah dan tidak membutuhkan pemisahan data antar layanan yang ketat.
3. Tim engineering Anda kecil dan tidak memiliki personel khusus infrastruktur/DevOps untuk menangani troubleshooting cluster Kafka saat terjadi split-brain atau disk full.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Sebagai arsitek yang pernah jatuh bangun di berbagai skala sistem, pesan saya jelas: Arsitektur yang baik adalah arsitektur yang paling sedikit menimbulkan masalah pada pukul 3 pagi.

Apache Kafka bukanlah peluru perak (silver bullet). Ia adalah mesin industri berat yang luar biasa perkasa, tetapi berbahaya jika dioperasikan tanpa pengemudi yang kompeten. Jika skala sistem dan volume data Anda memang menuntut skalabilitas horizontal tanpa batas, Kafka adalah investasi terbaik yang akan menyelamatkan tidur malam Anda. Namun, jika skala Anda masih kecil, mulailah dengan kesederhanaan. Jangan membunuh semut dengan meriam nuklir.