Retry itu sering terasa seperti solusi paling aman: gagal, coba lagi. Tapi di sistem produksi, retry bisa jadi masalah baru kalau step sebelumnya sudah telanjur mengubah state.
Artikel ini membahas kenapa workflow multi-step butuh rollback, compensating action, dan idempotency, bukan cuma retry otomatis. Cloudflare baru merilis saga rollbacks untuk Cloudflare Workflows, dan menurut gua ini contoh bagus buat memahami partial failure: kondisi saat proses gagal di tengah, sementara sebagian efek samping sudah terjadi. Kalau lu bikin backend, automation, payment flow, email pipeline, deployment tool, atau AI agent yang menjalankan aksi nyata, konsep ini wajib masuk radar.
Apa itu Cloudflare Workflows?
Cloudflare Workflows adalah engine untuk menjalankan proses multi-step yang durable. Durable di sini maksudnya workflow bisa menyimpan state, melakukan retry, dan lanjut lagi walau ada error sementara. Contoh sederhananya: user checkout, sistem reserve stok, charge payment, bikin invoice, kirim email, lalu update CRM.
Di atas kertas, proses kayak gitu kelihatan linear. Tapi di dunia nyata, setiap step bisa ngomong ke sistem berbeda: database internal, payment provider, email service, object storage, webhook vendor, atau API pihak ketiga. Begitu ada banyak sistem eksternal, error bukan cuma “request gagal”. Error bisa berarti “sebagian sudah sukses, sebagian belum”.
Masalahnya: gagal di tengah itu beda dengan gagal dari awal
Bayangin workflow ini:
- Reserve stok barang.
- Charge kartu customer.
- Buat order di database.
- Kirim email konfirmasi.
Kalau step pertama gagal, relatif simpel: workflow berhenti, belum ada efek besar. Tapi kalau step kedua berhasil, lalu step ketiga gagal, sistem lu masuk wilayah abu-abu. Uang mungkin sudah tertagih, stok mungkin sudah tertahan, tapi order belum tercatat rapi.
Di titik ini, retry doang belum tentu cukup. Kalau lu retry tanpa desain yang bener, lu bisa charge dua kali, reserve stok dua kali, kirim email ganda, atau bikin data yang susah dijelaskan ke customer support. Itulah kenapa workflow produksi butuh recovery plan, bukan cuma tombol “coba lagi”.
Apa itu saga rollback?
Saga adalah pola desain untuk menjaga konsistensi pada proses bisnis yang tersebar di banyak service atau sistem. Berbeda dari database transaction biasa yang bisa rollback otomatis, saga biasanya butuh compensating transaction: aksi balasan yang dirancang developer untuk mengurangi atau membatalkan efek step sebelumnya.
Contoh: kalau sistem sudah reserve stok tapi payment gagal, compensating action-nya bisa melepas reserve stok. Kalau email sudah terkirim, lu tidak bisa “menarik” email itu dari inbox user. Yang bisa lu lakukan mungkin kirim email koreksi, update status, atau membuat event audit agar support tahu konteksnya.
Cloudflare menyebut fitur baru ini sebagai saga rollbacks untuk Cloudflare Workflows. Intinya, developer bisa mendeklarasikan logic rollback pada step tertentu, sehingga saat workflow gagal, sistem punya urutan kompensasi yang lebih jelas.
Rollback bukan mesin waktu
Bagian ini penting: rollback di distributed system bukan berarti semua bisa dikembalikan seperti tidak pernah terjadi. Banyak efek samping tidak bisa di-undo secara sempurna.
- Email yang sudah terkirim tetap terkirim.
- Webhook yang sudah diterima vendor tetap punya jejak.
- Payment eksternal mungkin butuh refund, bukan undo instan.
- File yang sudah diproses bisa perlu status koreksi, bukan dihapus diam-diam.
Jadi, mental model yang lebih sehat bukan “rollback = batal total”. Lebih tepat: rollback = rencana kompensasi agar sistem kembali ke state yang aman, bisa dijelaskan, dan tidak merugikan user.
Retry, rollback, dan idempotency punya tugas berbeda
Biar gampang, gua bedain tiga konsep ini:
| Konsep | Fungsi utama | Contoh |
|---|---|---|
| Retry | Mengulang operasi yang gagal sementara | Coba kirim request lagi karena timeout |
| Idempotency | Mencegah aksi ganda saat operasi diulang | Payment pakai idempotency key agar tidak double charge |
| Rollback / compensation | Merapikan efek samping saat workflow gagal di tengah | Lepas reserve stok kalau payment gagal |
Retry tanpa idempotency bisa menggandakan side effect. Idempotency tanpa rollback bisa mencegah double action, tapi belum tentu merapikan state yang sudah setengah jalan. Rollback tanpa observability juga bahaya, karena lu tidak tahu kompensasi mana yang berhasil dan mana yang gagal.
Contoh praktis buat backend developer
Misal lu punya automation untuk onboarding user B2B:
- Buat workspace.
- Tambahkan admin pertama.
- Provision billing plan.
- Kirim invitation email.
- Trigger sync ke CRM.
Kalau billing plan gagal setelah workspace dibuat, apa yang harus terjadi? Pilihannya bisa beda-beda tergantung produk:
- Hapus workspace yang baru dibuat.
- Tandai workspace sebagai
setup_failed. - Jadwalkan retry billing dengan idempotency key.
- Kirim alert internal agar support bisa follow up.
- Tunda invitation email sampai billing jelas.
Yang berbahaya adalah tidak punya jawaban. Karena saat incident terjadi, tim biasanya baru sadar bahwa “retry otomatis” bukan desain recovery. Itu cuma salah satu alat.
Checklist sebelum lu bikin workflow produksi
Kalau lu lagi bikin proses multi-step, coba jawab checklist ini sebelum deploy:
- Step mana yang punya side effect eksternal? Tandai semua aksi yang menyentuh payment, email, vendor API, file, atau sistem lain.
- Step mana yang aman di-retry? Jangan anggap semua request aman diulang.
- Apakah ada idempotency key? Terutama untuk payment, order creation, webhook, dan job queue.
- Kalau step ke-N gagal, apa kompensasi untuk step sebelumnya? Tulis eksplisit, jangan simpan di kepala.
- Apa state akhir yang aman? Kadang bukan “sukses” atau “gagal”, tapi
needs_manual_review. - Apakah rollback juga bisa gagal? Kalau iya, lu butuh alert, audit log, dan jalur manual.
- Apakah user dan support bisa memahami statusnya? State internal yang rapi percuma kalau tidak bisa dijelaskan.
Kenapa ini relevan juga buat AI agent dan automation
Gua melihat pola yang sama mulai muncul di AI agent. Banyak demo agent terlihat keren karena agent bisa klik UI, edit file, publish draft, run command, atau deploy aplikasi. Tapi begitu agent diberi akses untuk bertindak, pertanyaan production-nya berubah: kalau aksi ketiga gagal, apa yang terjadi dengan aksi pertama dan kedua?
AI agent yang serius tidak cukup punya chat history. Dia butuh action log, idempotency, permission boundary, rollback plan, dan state machine yang jelas. Kalau agent lu bisa membuat pull request, mengubah konfigurasi Cloudflare, atau menjalankan job deploy, lu perlu tahu cara menghentikan, mengulang, dan membatalkan sebagian efeknya.
Di sinilah pelajaran dari Cloudflare Workflows terasa relevan. Durable execution bukan cuma soal “task panjang tetap jalan”. Durable execution juga soal bagaimana sistem menghadapi error tanpa meninggalkan kekacauan yang harus dibersihkan manusia tengah malam.
Takeaway singkat
- Retry itu penting, tapi bukan obat semua error.
- Partial failure lebih bahaya daripada gagal dari awal karena state sudah berubah sebagian.
- Saga rollback memakai compensating action, bukan rollback ajaib seperti database transaction lokal.
- Idempotency wajib dipikirkan bareng retry agar aksi tidak dobel.
- Workflow produksi butuh observability dan state yang bisa dijelaskan ke manusia.
FAQ singkat
Apakah saga rollback sama dengan database transaction?
Tidak. Database transaction biasanya bekerja dalam satu database dengan rollback otomatis. Saga dipakai saat proses tersebar di banyak service atau sistem eksternal, sehingga rollback perlu dirancang sebagai aksi kompensasi.
Apakah semua workflow perlu saga?
Tidak. Workflow sederhana tanpa side effect eksternal mungkin cukup dengan retry dan error handling biasa. Saga mulai penting saat workflow menyentuh payment, inventory, email, vendor API, provisioning, atau proses bisnis yang tidak boleh setengah matang.
Kalau rollback bisa gagal juga, buat apa dipakai?
Justru karena rollback bisa gagal, lu perlu mendesainnya eksplisit. Minimal sistem punya audit log, status yang jelas, alert, dan jalur manual. Tanpa itu, kegagalan tetap terjadi, tapi lebih sulit dilacak.
Penutup
Menurut gua, pelajaran terbesar dari saga rollbacks bukan cuma fitur baru Cloudflare. Pelajaran utamanya: sistem produksi yang sehat tidak cuma mikir “gimana caranya sukses”, tapi juga “kalau gagal di tengah, apa rencana pulangnya?”
Kalau lu lagi bikin backend, automation, atau AI agent yang mulai menyentuh aksi nyata, jangan berhenti di retry. Tulis side effect-nya, desain idempotency-nya, siapkan kompensasinya, dan pastikan state akhirnya bisa dijelaskan. Itu bedanya demo yang keren dengan sistem yang bisa dipercaya.
