Replay Strategy #

Kenapa Penting, Masalah yang Diselesaikan, dan Best Practice Implementasinya

Dalam dunia distributed systems, kegagalan bukanlah kemungkinan — melainkan kepastian. Network timeout, service crash, message duplication, partial failure, hingga human error adalah bagian dari keseharian sistem modern. Di sinilah Replay Strategy memegang peran krusial.

Artikel ini akan membahas:

Apa itu Replay Strategy
Kenapa Replay Strategy penting
Masalah nyata yang diselesaikan Replay Strategy
Jenis-jenis Replay Strategy
Best practice implementasi Replay Strategy
Contoh kasus nyata di sistem produksi

Apa Itu Replay Strategy? #

Replay Strategy adalah pendekatan dalam sistem software untuk memproses ulang (replay) event, message, atau request yang gagal diproses, belum selesai, atau perlu diverifikasi ulang, tanpa menyebabkan efek samping yang tidak diinginkan.

Replay bisa terjadi pada:

Event (Kafka, Pub/Sub, EventBridge)
Message Queue (SQS, RabbitMQ)
HTTP request
Command dalam CQRS
Job async / background task

Intinya:

Replay Strategy memastikan sistem bisa “mengulang” proses dengan aman dan deterministik.

Kenapa Penting? #

Kegagalan Bersifat Inevitable #

Di sistem terdistribusi:

Network akan timeout
Service akan down
Database akan overload
Consumer akan crash

Tanpa replay, kegagalan berarti data hilang atau state rusak.

Menjamin Reliability dan Durability #

Replay memungkinkan:

Data tidak hilang meskipun consumer mati
Proses dapat dilanjutkan setelah crash
Recovery tanpa manual intervention

Ini adalah fondasi dari:

At-least-once delivery
Eventually consistent systems

Debugging & Incident Recovery #

Replay bukan hanya untuk error:

Reprocess event lama setelah bug fix
Audit ulang transaksi
Rebuild read model (CQRS)
Re-sync data antar sistem

Masalah yang Diselesaikan #

❌ Tanpa Replay Strategy #

Event gagal → data hilang
Manual rerun script (riskan)
Duplicate processing → double charge
Tidak bisa recovery otomatis

✅ Dengan Replay Strategy #

Event gagal → retry atau dead-letter
Duplicate → ditangani idempotency
Bisa reprocess kapan saja
Sistem lebih predictable

Jenis-Jenis #

Retry (Immediate Replay) #

Memproses ulang event secara langsung ketika gagal.

Contoh:

Retry 3x
Backoff 1s → 5s → 30s

⚠️ Risiko:

Retry storm
Membebani downstream service

Delayed Retry / Backoff Replay #

Replay dilakukan setelah delay tertentu.

Best practice:

Exponential backoff
Jitter (random delay)

Cocok untuk:

Transient failure
Rate limit issue

Dead Letter Queue (DLQ) #

Jika gagal terus, event dipindahkan ke DLQ.

Manfaat:

Tidak menghambat consumer utama
Bisa dianalisis manual
Bisa direplay secara selektif

Ini best practice wajib di sistem event-driven.

Manual Replay #

Event disimpan dan bisa diputar ulang secara manual:

Berdasarkan timestamp
Berdasarkan event ID
Berdasarkan partition / offset

Umum di:

Kafka
Event sourcing
Financial systems

Event Sourcing Replay #

Dalam event sourcing:

Replay = membangun ulang state
Event adalah source of truth

Digunakan untuk:

Rebuild projection
Migrasi schema
Bug fixing logic

Tantangan Utama #

Duplicate Processing #

Replay hampir selalu menyebabkan duplicate event.

Solusi:

Idempotency
Deduplication key
Exactly-once illusion (bukan real)

Ordering #

Replay bisa mengubah urutan event.

Solusi:

Partition key
Sequence number
Versioning

Side Effects #

Replay bisa:

Mengirim email ulang
Double charge payment
Trigger webhook lagi

Solusi:

Pisahkan command dan side effect
Gunakan state check

Best Practice #

Kombinasi Replay + Idempotency #

Replay tanpa idempotency = bencana.

Contoh idempotency key:

order_id
event_id
request_id

Pattern:

IF already_processed(event_id):
    skip
ELSE:
    process

Simpan Event Secara Durable #

Jangan hanya rely on memory
Gunakan persistent storage
Event harus bisa direplay kapan saja

Pisahkan Retry dan DLQ #

Rule umum:

Retry → untuk transient error
DLQ → untuk logical / permanent error

Replay Otomatis Tanpa Kontrol (❌) #

Replay massal bisa:

Overload system
Mengganggu live traffic

Gunakan:

Throttling
Batch replay
Feature flag

Logging dan Observability Wajib #

Replay tanpa visibility = blind operation.

Minimal:

Log replay reason
Metric retry count
Trace replayed event

Contoh Kasus Nyata #

Kasus: Payment Processing #

Flow:

Order dibuat
Event PaymentRequested
Payment gateway timeout

Tanpa replay:

Order stuck
Customer bingung

Dengan replay:

Event masuk retry
Jika gagal → DLQ
Setelah gateway normal → replay DLQ
Idempotency memastikan tidak double charge

Replay Strategy ≠ Retry Saja #

Ini kesalahan umum engineer junior.

Replay Strategy adalah:

Design decision
Architectural concern
Operational tool

Bukan sekadar:

for i := 0; i < 3; i++ { retry() }

Penutup #

Replay Strategy adalah fondasi penting dalam sistem modern karena:

Kegagalan tidak bisa dihindari
Sistem harus bisa recovery
Data tidak boleh hilang
Operasional harus terkendali

Tanpa replay strategy:

Sistem Anda bukan “distributed system”, tapi “distributed failure”.

Dengan replay strategy yang baik:

Sistem lebih resilient
Debugging lebih mudah
Engineer lebih tenang 😄