Event-Driven Architecture: Kapan Sebaiknya TIDAK Dipakai

Event-driven architecture adalah pola yang semua orang ingin cantumkan di CV tapi hampir tidak pernah dipertanyakan. Janjinya menggoda: service yang decoupled, skalabilitas tanpa batas, sistem yang bereaksi terhadap dunia alih-alih melakukan polling. Saya sudah merilis alur event-driven di production dan akan terus melakukannya. Tapi saya juga pernah melihat tim, termasuk diri saya di masa lalu, mengambil sistem CRUD yang mudah dipahami lalu mengubahnya menjadi misteri pembunuhan terdistribusi di mana tidak ada yang bisa menjawab pertanyaan operasional paling sederhana: apa yang terjadi, dalam urutan apa, dan kenapa.

Tulisan ini adalah kerangka keputusan yang dulu saya harap ada yang memberikannya sebelum saya menyambungkan message broker pertama ke sebuah ERP. Jawaban singkatnya di awal: kalau sistem Anda muat di satu database, tim Anda muat di satu ruangan, dan workflow Anda butuh jawaban sekarang bukan nanti, kemungkinan besar Anda belum butuh event. Begini cara memastikannya.

Apa yang Sebenarnya Anda Dapat dari Event

Mari adil dulu terhadap polanya. Tulisan klasik Martin Fowler membedakan event notification, event-carried state transfer, event sourcing, dan CQRS, dan masing-masing menyelesaikan masalah coupling yang spesifik. Event notification membuat producer bisa mengumumkan bahwa sesuatu terjadi tanpa perlu tahu siapa yang mendengarkan. Event-carried state transfer membuat consumer menyimpan salinan datanya sendiri sehingga bisa menjawab query tanpa memanggil sistem sumber. Ini properti yang nyata dan berharga ketika Anda punya banyak tim dan banyak service yang saling bersinggungan.

AWS membingkai ide yang sama secara operasional: producer, router, dan consumer yang scale, gagal, dan deploy secara independen. Kalau pipeline pemrosesan gambar Anda kena lonjakan trafik 100x sementara service billing tidak, menaruh queue di antara keduanya jelas benar. Pertanyaannya tidak pernah apakah event itu berfungsi. Pertanyaannya adalah apakah masalah yang diselesaikannya memang masalah yang Anda hadapi hari ini.

Empat Biaya yang Tidak Pernah Masuk Slide Presentasi

Setiap pola arsitektur adalah pertukaran. Inilah yang Anda bayar untuk event, dan Anda membayarnya sejak hari pertama, bukan saat scale.

Lima Tanda Event Akan Memperburuk Sistem Anda

Dari pengalaman saya membangun sistem NestJS dan PostgreSQL untuk SMB Indonesia, ini bendera merah bahwa desain event-driven justru akan mengurangi nilai:

• Producer dan consumer dipegang tim yang sama dan deploy bersamaan. Anda membayar pajak decoupling penuh untuk men-decouple nol hal. Function call atau transaksi database sudah cukup.
• Alur bisnis butuh jawaban langsung dan otoritatif. Reservasi stok, otorisasi pembayaran, booking kursi: kalau pengguna harus tahu hasilnya sebelum lanjut, event di tengah hanya menambah latency dan mode kegagalan.
• Anda butuh urutan ketat lintas entitas. Broker umumnya hanya menjamin urutan per partition atau per queue. Kalau logika domain Anda rusak saat pesan B tiba sebelum pesan A, Anda akan berakhir membangun ulang lapisan serialisasi yang sebenarnya sudah diberikan database secara gratis.
• Seluruh beban tulis Anda muat nyaman di satu instance PostgreSQL. Kebanyakan sistem SMB puncaknya di bawah beberapa ratus write per detik. Postgres menangani itu di mesin 4 vCPU dengan sisa tenaga. Skalabilitas yang tidak Anda butuhkan bukan aset, itu inventori.
• Tidak ada anggota tim yang pernah mengoperasikan broker di production. Insiden poison message pertama jam 2 pagi bukan waktu yang tepat untuk belajar cara kerja dead-letter queue.

Panggilan Synchronous vs Event: Perbandingan Jujur

Ini tabel yang saya gambar di whiteboard saat tim sedang memutuskan. Tidak ada kolom yang lebih baik; keduanya tagihan yang berbeda.

Contoh Nyata: Alur Approval yang Tidak Butuh Kafka

Di salah satu proyek ERP, approval purchase order awalnya menerbitkan event POApproved yang diambil consumer inventory untuk mereservasi stok. Di atas kertas, decoupling yang indah. Praktiknya, kedua service dipelihara tiga engineer yang sama dan di-deploy dari monorepo yang sama. Saat payload cacat membuat consumer crash, retry menunda reservasi stok 40 detik sementara staf procurement menatap stok bebas yang seharusnya sudah terkunci.

Kami mengganti event itu dengan satu transaksi database yang meng-update purchase order dan reservasi stok sekaligus. Diagram di bawah adalah kondisi sebelum dan sesudah. Satu kelas insiden terhapus, latency hilang, dan kode menyusut sepertiga. Kami mempertahankan event di tempat yang memang layak: notifikasi ke warehouse reporting dan pengiriman email, di mana jeda 40 detik tidak merugikan apa pun.

-- What "eventually consistent" looked like in practice:
-- the PO was approved, but stock reservation lagged 40s behind
-- because a consumer was retrying a poison message.

Approval service     Inventory service        User sees
────────────────     ─────────────────        ─────────
10:00:00 PO approved
10:00:00 emit POApproved
                     10:00:01 crash (bad payload)
                     10:00:05 retry 1 → crash
                     10:00:15 retry 2 → crash
                     10:00:40 retry 3 → ok     "Why is stock
                     10:00:40 reserve stock     still free?!"

-- The synchronous version is one transaction:
BEGIN;
UPDATE purchase_orders SET status = 'approved' WHERE id = $1;
UPDATE stock_items SET reserved = reserved + qty WHERE ...;
COMMIT;  -- consistent at 10:00:00, every time

Checklist Keputusan yang Benar-Benar Saya Pakai

Sebelum queue atau topic mana pun masuk desain saya, ia harus lolos lima pertanyaan ini, berurutan:

1. Apakah ada ketimpangan latency atau availability yang nyata antara producer dan consumer, seperti upload yang melonjak memberi makan pemrosesan yang lambat? Kalau tidak, berhenti di sini dan pakai panggilan atau transaksi.
2. Bisakah hasil bisnis mentolerir jeda bermenit-menit dan urutan yang sesekali acak? Kalau tidak, langkah itu tetap synchronous semau apa pun diagram topic-nya terlihat elegan.
3. Apakah producer dan consumer dimiliki tim berbeda dengan ritme deploy berbeda? Men-decouple tim adalah alasan sah terkuat untuk event. Men-decouple kode Anda dari dirinya sendiri bukan.
4. Apakah consumer idempotent sudah didesain sebelum pesan pertama mengalir? At-least-once delivery berarti duplikat adalah kepastian, bukan edge case.
5. Apakah ada budget operasional: monitoring consumer lag, strategi dead-letter, dan orang yang bisa menguras queue dalam tekanan? Kalau jawabannya jujur tidak, tunda polanya, bukan fiturnya.

Di Mana Event Benar-Benar Menang

Supaya tulisan ini bukan serangan sepihak: saya menjalankan alur event-driven dengan senang hati di production hari ini, dan mereka layak dipertahankan di tiga tempat.

• Fan-out side effect: satu fakta bisnis, banyak reaksi independen. Invoice dibayar; accounting, email, analytics, dan portal pelanggan semuanya peduli, dan tidak ada yang boleh memblokir yang lain.
• Load leveling: producer yang bursty memberi makan consumer yang dibatasi rate, seperti bulk import yang menetes ke API pihak ketiga yang hanya mengizinkan lima request per detik.
• Integrasi lintas sistem: ketika consumer adalah sistem perusahaan lain atau ERP legacy yang tidak bisa Anda panggil secara synchronous, event log adalah kontrak terbersih yang bisa Anda tawarkan.

Membosankan Dulu, Event Saat Sudah Layak

Event-driven architecture adalah alat untuk mengelola kompleksitas organisasi dan profil beban, bukan lencana kedewasaan. Sistem yang paling saya banggakan dimulai sebagai monolith dengan satu database PostgreSQL, menambah transactional outbox saat pekerjaan async muncul, dan baru memperkenalkan broker sungguhan ketika kebutuhan fan-out atau load-leveling konkret datang membawa angka.

Intinya: setiap batas async yang Anda tambahkan harus membayar sewa berupa masalah decoupling atau scaling nyata yang ia selesaikan. Kalau tidak bisa, biarkan panggilan tetap synchronous, pertahankan transaksinya, dan nikmati kemampuan membaca perilaku sistem Anda dari satu stack trace. Diri Anda yang jam 2 pagi akan berterima kasih.