Pendahuluan: Kapan Menentukan Arsitektur?

Untuk workflow skala menengah, keputusan antara event-driven dan batch processing harus segera ditentukan karena mempengaruhi latensi, konsistensi data, dan biaya operasional. Jika kebutuhan utama adalah merespons perubahan data secara cepat, event-driven cenderung lebih cocok; jika proses dapat dijadwalkan dengan interval jelas dan data dikumpulkan, batch menjadi pilihan yang praktis.

Artikel ini menjabarkan kriteria pemilihan, trade-off teknis, dampak biaya operasional, dan pertimbangan maintainability agar tim engineering bisa memilih pendekatan yang sesuai dengan kondisi nyata.

Kriteria Pemilihan Arsitektur

1. Karakteristik Workload

Untuk workflow yang memiliki trigger dari event eksternal (misalnya notifikasi pembayaran, unggahan file), event-driven meminimalkan delay karena pemrosesan dimulai langsung setelah event terjadi. Workflow dengan volume tinggi dan pola burst juga lebih baik ditangani event-driven karena sistem dapat mengatur antrian dan autoscaling berdasarkan kedatangan event.

Sementara batch cocok untuk proses pengumpulan data periodik, seperti perhitungan laporan harian atau pengiriman faktur, di mana semua input sudah tersedia dalam satu titik waktu dan transaksi bersifat deterministik.

2. Pengharapan Latensi dan Throughput

Jika latensi end-to-end harus tetap rendah (misalnya response time tidak boleh lebih dari beberapa detik), event-driven bisa memberikan respon cepat karena tidak menunggu window batch. Namun, throughput event-driven bergantung pada kemampuan sistem antrian dan worker untuk menskalakan secara horizontal.

Batch processing unggul jika throughput keseluruhan lebih penting daripada latensi per item karena idealnya dijalankan pada jendela waktu saat beban sistem rendah, memungkinkan proses paralel tanpa overhead komunikasi realtime.

Analisis Trade-Off Teknis

Latensi, Throughput, dan Konsistensi

Event-driven memberikan latensi rendah per event, tetapi konsistensi data harus dijaga melalui pola idempotensi atau transactional outbox karena pesan mungkin diproses ulang. Bila state harus selaras atomik, perlu pendekatan tambahan seperti distributed transactions atau sagas.

Batch processing menanggung latensi tinggi per siklus namun lebih mudah menjaga konsistensi karena seluruh data diproses dalam satu run. Trade-off yang penting adalah bahwa batch bisa mempercepat throughput dengan mengotomasi parallelisme dalam satu job, tetapi latency spike terjadi ketika job mulai atau selesai.

Kesalahan Umum yang Harus Dihindari

  • Untuk event-driven: mengabaikan mekanisme retry dan dead-letter queue sehingga error event menjadi hilang.
  • Untuk batch: membuat job terlalu besar sehingga mudah gagal dan sulit di-debug, serta menggabungkan terlalu banyak dependensi eksternal dalam satu siklus.

Biaya Operasional dan Maintainability

Resource dan Monitoring

Event-driven memerlukan broker (Kafka, RabbitMQ, atau AWS SNS/SQS) dan worker yang terus berjalan, sehingga monitoring harus mencakup antrian, lag consumer, dan health worker. Sering kali perlu alert ketika throughput turun atau backlog menumpuk.

Batch processing dapat dijalankan di scheduler seperti cron, Airflow, atau Argo Workflows dengan resource yang dipanggil hanya saat job dijalankan, sehingga biaya tetap lebih stabil. Namun, observability harus fokus pada durasi job, keberhasilan, dan dampak terhadap sistem downstream.

Deployment dan Debugging

Event-driven memperumit deployment karena worker harus sinkron dengan schema event; perubahan schema memerlukan versi atau contract testing. Namun, event-driven inline dengan microservice karena event bisa menjadi boundary domain.

Batch lebih mudah di-debug karena job biasanya punya log terpusat dan dapat dijalankan ulang secara lokal. Tetapi, jika ada banyak batch job saling bergantung, dependency graph harus dikelola dengan jelas agar perubahan tidak menyebabkan kegagalan cascade.

Contoh Pola Arsitektur

Event-Driven untuk Notifikasi Pembayaran

Skenario: setelah pengguna melakukan pembayaran, sistem perlu memproses validasi, update saldo, dan kirim notifikasi.

Arsitektur:

  • Payment Service mengeluarkan event payment.completed ke Kafka topic.
  • Ledger Worker membaca event dan memperbarui database pengguna dengan transaksi baru.
  • Notification Worker mengirim email/SMS berdasarkan payload.

Setiap worker memakai Retry policy dan dead-letter topic. Untuk debugging, setiap event diberi trace-id agar bisa ditelusuri ke seluruh pipeline.

Batch untuk Laporan Harian

Skenario: agregasi transaksi per pengguna setiap tengah malam untuk laporan keuangan.

Arsitektur:

  • Scheduler (misalnya Airflow) menjalankan dag yang memanggil job compute-aggregates.
  • Job terhubung ke database OLTP, membaca data transaksi dalam range waktu, lalu menulis hasil ke data warehouse.
  • Jika job gagal, Airflow secara otomatis retry dan memberikan log lengkap.

Pemantauan berfokus pada durasi job dan ketepatan jadwal; rollback dilakukan dengan rerun setelah memperbaiki data input.

Kesimpulan dan Panduan Pemilihan

Gunakan arsitektur event-driven bila:

  • Anda butuh latensi rendah dan respon cepat terhadap perubahan.
  • Workflow bersifat asynchronous dengan banyak dependensi yang dapat diparalelkan.
  • Anda sanggup mengelola observability antrian dan retry logic.

Pilih batch processing bila:

  • Data sudah tersedia dalam batch dan konsistensi global lebih penting.
  • Job dapat dijadwalkan saat sumber daya tersedia dan pola akses data sudah diketahui.
  • Anda ingin debugging deterministik dengan log terpusat.

Banyak sistem skala menengah mengombinasikan keduanya: event-driven untuk respons realtime dan batch untuk reporting komprehensif. Kunci utamanya adalah mengevaluasi latensi, konsistensi, dan kemampuan operasi secara bersamaan sebelum menentukan arah arsitektur.