Untuk sistem fintech dengan throughput tinggi seperti order matching dan settlement, keputusan cepat antara event-driven dan batch processing harus didasari pada kebutuhan latency, kompleksitas operasional, dan kemampuan recovery. Event-driven cocok saat push state realtime diperlukan; batch cocok bila operasional dapat dikompensasi dan biaya throughput per detik harus dikontrol.

Skenario Fintech yang Menuntut Throughput dan Ketepatan

Bayangkan order book exchange yang menerima ribuan pesanan per detik. Order matching mesti melakukan pencocokan harga dan posisi margin dengan minimum latency agar tidak ada slippage. Pada sisi settlement, fund transfer menggabungkan data transaksi dari berbagai clearing house dan harus tahan terhadap keterlambatan yang bisa memicu penalti regulasi.

Dalam skenario ini, masuknya data (order, fill, settlement instruction) harus diproses dengan throughput tinggi (>10k event/detik) dan ketepatan state. Jadi arsitektur pemrosesan data harus mempertimbangkan latency end-to-end, durasi recovery saat kegagalan, dan beban storage/transfer tambahan.

Arsitektur Event-Driven: Stream dan Pub/Sub untuk Responsif

Event-driven processing memecah workflow menjadi consumer yang merespons event stream secara langsung. Misalnya:

// contoh consumer sederhana pada Kafka (pseudo code agar sesuai konsep)
var consumer = kafka.consumer("order-matching");
consumer.subscribe("orders");
while (consumer.poll()) {
  var event = consumer.read();
  if (validate(event)) {
    orderBook.match(event);
    metrics.increment("latency", now() - event.timestamp);
  }
}

Dengan pendekatan ini, latency penanganan bisa turun ke sub detik. Jika menggunakan stream processor (Apache Kafka Streams, Flink, atau AWS Kinesis Data Analytics), Anda bisa menjalankan transformasi stateful, join antar-topik, dan windowing secara near real-time.

Pro:

  • Latensi rendah dan kontinu; cocok untuk order matching dan pemberitahuan risiko.
  • Scale-out horizontal; consumer baru bisa ditambahkan saat throughput naik.
  • Observability natural melalui offsets, consumer lag, dan trace request.

Kontra:

  • Operational complexity: memerlukan monitoring consumer lag, offset management, dan state store durable.
  • Biaya penyimpanan dan transfer data tinggi pada cloud karena record terus ditulis dan direplikasi.
  • Skill set tim harus mencakup stream processing, schema evolution, dan disaster recovery.

Arsitektur Batch: Cron dan Bulk Job untuk Keteraturan Biaya

Batch processing menjalankan job terjadwal (cron) atau pemrosesan bulk pada waktu tertentu. Contoh tipikal: settlement file digabungkan setiap 5 menit atau 1 jam, disinkronisasi ke GL (General Ledger), lalu dikirim ke sistem core banking.

Pro:

  • Pilihan biaya lebih mudah diprediksi; compute dapat dimatikan di luar jadwal.
  • Sederhana bagi tim yang terbiasa dengan ETL tradisional dan SQL-based aggregations.
  • Testing dan replay lebih deterministik karena data diproses dalam window jelas.

Kontra:

  • Latency tinggi karena data dikumpulkan lalu diproses; tidak ideal untuk respon risiko realtime.
  • Batch job besar rentan gagal akibat data corrupt, sehingga recovery memerlukan checkpoint dan restart manual.
  • Visibility terhadap status job memerlukan orchestrator seperti Airflow, dan debugging sering melibatkan inspeksi log dan output file.

Perbandingan Aspek Kritis

DimensiEvent-DrivenBatch
LatencySub-detikan untuk order matching; penanganan risiko lebih cepat.Interval pengolahan waktu-tunda; ideal untuk settlement yang bisa ditunda.
Kompleksitas OperasionalTinggi: cluster stream, schema registry, consumer lag monitoring.Moderate: orchestrator job, data staging, retry plan.
Biaya CloudLebih tinggi karena throughput kontinu dan replikasi state.Lebih hemat karena compute dapat dijadwalkan dan disk hanya dipakai saat batch.
MaintainabilityMemerlukan tim dengan skill distribusi stateful stream.Mudah bagi tim SQL/ETL; versi job dan dependency lebih transparan.
ObservabilityLebih granular: lag, event trace, SLA alert.Job status, runtime log; wajar tapi kurang real-time.
RecoveryCheckpoint otomatis, replay per partition.Manual rerun, perlu data staging dan idempotence.
Storage/TransferLog event panjang, replikasi, schema registry.Temporary staging file; data hanya ditransfer per run.
SkillStream processing, distributed consensus, monitoring distributed commit.ETL, job orchestration, SQL tuning.

Observability dan Recovery di Kedua Pendekatan

Event-driven harus memikirkan observability seperti consumer lag, commit log, dan distributed tracing agar tidak kehilangan event. System harus siap memeriksa state stores dan replay partition saat kegagalan. Batch lebih sederhana: job scheduler sudah memberikan status, tapi debugging memerlukan log dan data snapshot.

Kedua pendekatan sebaiknya menerapkan API observability (metrics, alert) dan backup data mentah sehingga dapat di-restore. Penting juga menyiapkan idempotence agar replay tidak menggandakan settlement.

Rekomendasi Situasional

Pilih event-driven bila Anda butuh realtime reaction terhadap order dan risiko, mampu mengelola throughput 10k+ event/detik, dan tim siap memonitor stream cluster. Kombinasikan dengan pub/sub (misalnya Kafka, Pulsar) untuk orkestrasi microservice matching, pricing, dan risk scoring.

Pilih batch processing bila workflow fintech Anda terikat jadwal settlement (misal: nightly billing), latency tidak kritis, dan Anda ingin predictability biaya cloud dengan scheduler (Airflow, Prefect) plus data warehouse untuk audit trail.

Dalam praktik, kombinasi hibrida juga umum: event-driven untuk order path, batch untuk reporting/settlement. Pastikan ada lapisan buffer (stream-to-batch) yang menyimpan raw event untuk replay sehingga kedua pendekatan tetap sinkron.