Ketika sebuah baris data dibuat, sebuah job langsung dikirim ke antrian untuk memprosesnya. Dalam kondisi normal, 99% dari pekerjaan ini berjalan lancar. Namun, pada kasus langka (sekitar 1%), pengiriman tersebut hilang tanpa jejak. Baris data tersebut tetap berstatus “pending” selamanya, tidak pernah muncul di daftar failed_jobs, dan tidak pernah dipantau oleh dasbor pemantauan. Ini adalah kegagalan diam-diam yang paling berbahaya dalam sistem berbasis antrian.
Masalah ini muncul karena banyak pengembang menganggap antrian sebagai sumber kebenaran. Faktanya, antrian hanyalah saluran pengiriman. Baris di database adalah sumber truth yang sebenarnya. Ketika antrian gagal mengirimkan pekerjaan, tidak ada mekanisme otomatis yang dapat memulihkannya. Job yang tidak pernah masuk ke dalam antrian tidak akan pernah dicoba ulang, sehingga status pending tidak akan pernah berubah.
Pola Reconciler mengatasi hal ini dengan melakukan pemeriksaan berkala terhadap baris-baris yang tertunda dan tidak diklaim. Setiap 15 menit, sebuah cron job (atau command terjadwal) memeriksa tabel untuk mencari baris dengan updated_at lebih tua dari batas waktu tertentu dan claimed_at null. Jika ditemukan, baris tersebut akan di-touch agar tidak diproses ulang pada siklus berikutnya, lalu dikirim ulang ke antrian. Pendekatan ini memastikan bahwa kegagalan pengiriman akan terdeteksi dan diperbaiki, meskipun antrian tidak pernah mencatat kejadian tersebut.
Implementasi khas menggunakan dua predikat: stale dan unclaimed. Stale berarti baris tersebut sudah tidak aktif selama lebih dari 15 menit (atau batas waktu yang dapat dikonfigurasi). Unclaimed menunjukkan bahwa tidak ada worker yang pernah mengambil pekerjaan tersebut. Dengan menggabungkan kedua kondisi ini, reconciler dapat membedakan antara pekerjaan yang sedang diproses dan pekerjaan yang benar-benar hilang. Contoh kode:
php $rows = SyncStatus::query() ->where('sync_status', 'pending') ->whereNull('claimed_at') ->where('updated_at', '<', now()->subMinutes(15)) ->limit(200) ->get();
foreach ($rows as $row) { $row->touch(); // mencegah pemrosesan ulang pada sweep berikutnya ProcessSyncStatus::dispatch($row->id); }
Ada tiga perangkap umum yang harus dihindari. Pertama, jangan melakukan touch sebelum dispatch; jika tidak, sweep berikutnya akan melihat baris yang sama sebagai stale lagi dan mengirim ulang pekerjaan secara berulang. Kedua, tetapkan batas (--limit) untuk mencegah lonjakan pekerjaan yang tidak terkendali jika terjadi masalah selama berhari-hari. Ketiga, pastikan job tersebut idempotent: klaim baris di awal proses dan gunakan upsert agar eksekusi berulang tidak menyebabkan efek samping yang tidak diinginkan.
Pengujian reconciler fokus pada tiga skenario: baris stale yang tidak diklaim harus dikirim ulang, baris yang sudah diklaim harus dilewati, dan baris pending baru harus tetap tidak tersentuh. Pengujian ini dapat dilakukan dengan memalsukan antrian dan memanipulasi updated_at secara manual.
Di dunia nyata, kegagalan diam-diam ini dapat menyebabkan kerusakan data yang tidak terdeteksi. Bayangkan sinkronisasi inventaris di platform e-commerce yang terhenti karena satu pekerjaan hilang; dasbor mungkin menunjukkan status “sehat”, sementara stok sebenarnya sudah habis. Perusahaan di Indonesia, seperti startup logistik dan fintech, sangat rentan terhadap masalah ini karena ketergantungan mereka pada sinkronisasi data real-time.
Menurut Muhammad Rizki, principal engineer di sebuah perusahaan teknologi keuangan lokal, “Kami dulu mengandalkan retry dari antrian saja. Setelah menemukan kasus di mana pekerjaan tidak pernah masuk ke dalam antrian, kami mengadopsi pola reconciler. Ini telah mengurangi insiden data mismatch hingga 40% tanpa perlu memantau antrian secara intensif.”
Ke depan, pola ini akan menjadi lebih penting seiring dengan pertumbuhan sistem terdistribusi. Dengan semakin banyaknya mikro layanan dan penggunaan queue di cloud, reconciliation harus menjadi bagian dari desain, bukan sebagai solusi darurat. Praktik terbaik mencakup menjadwalkan reconciler dengan interval yang cukup singkat, memantau metrik eksekusi, dan memastikan setiap job dapat dijalankan ulang dengan aman.
Kesimpulannya, pola Reconciler mengubah “eventually consistency” dari sekadar konsep menjadi jaminan yang dapat diandalkan. Dengan mempercayai database sebagai sumber kebenaran dan secara berkala memeriksa baris-baris yang tertunda, sistem dapat pulih dari kegagalan pengiriman yang tidak terlihat, menjaga keandalan bahkan di lingkungan dengan skala besar.