Event yang dikirim lebih dahulu tidak selalu diproses lebih dahulu. Perbedaan jalur, retry, partisi, concurrency, dan waktu proses dapat membuat perubahan lama tiba setelah perubahan baru. Jika konsumen hanya menerapkan urutan kedatangan, status dapat mundur dan saldo dapat dihitung salah.
Mengapa urutan dapat berubah?
Satu event mungkin melewati jalur cepat sementara event sebelumnya menunggu dependensi. Retry dapat mengirim ulang pesan lama. Beberapa producer dapat menulis record yang sama. Jam mesin juga dapat berbeda, sehingga timestamp pembuatan bukan selalu urutan tepercaya. Skalabilitas yang membagi data ke partisi menambah boundary urutan.
Urutan harus didefinisikan per aggregate atau entity, bukan seluruh dunia. Perubahan satu order perlu terurut relatif terhadap order itu, tetapi tidak harus terhadap order lain. Hubungkan prinsip ini dengan eventual consistency.
Apa dampak bisnis yang mungkin terjadi?
| Domain | Urutan salah | Dampak |
|---|---|---|
| Order | Dikirim lalu kembali diproses | Pengalaman pelanggan membingungkan |
| Inventory | Koreksi mendahului penjualan lama | Saldo stok salah |
| HR | Perubahan jabatan lama menimpa baru | Hak akses keliru |
| Pembayaran | Refund terlihat sebelum settlement | Pelaporan sementara tidak konsisten |
Tidak semua domain boleh sekadar mengambil event terakhir yang tiba. Aturan transisi status harus menolak langkah yang tidak valid.
Informasi apa yang membantu menentukan urutan?
Event sebaiknya memiliki ID unik untuk deduplikasi, ID entity, versi atau sequence per entity, waktu kejadian bisnis, waktu produksi, serta jenis perubahan. Versi monotonik yang diterbitkan pemilik entity lebih kuat daripada timestamp konsumen. Namun, producer juga harus menjamin versi tidak berulang atau mundur.
Jika sumber tidak menyediakan versi, konsumen mungkin perlu membaca state terbaru sebelum menerapkan perubahan atau memakai aturan domain. Jangan membuat urutan global dari timestamp acak. Dokumentasikan makna field pada kontrak data.
Strategi apa yang tersedia?
Strategi umum mencakup menolak versi lama, buffering singkat untuk menunggu gap, menerapkan operasi komutatif, membaca state sumber, atau mengirim konflik ke review. Buffer menambah latensi dan tidak dapat menunggu selamanya. Menolak event lama memerlukan rekonsiliasi agar perubahan sah tidak hilang diam-diam.
Menambahkan delta unik dapat lebih aman daripada mengirim saldo absolut, tetapi hanya jika identitas delta mencegah penerapan ganda dan aturan domain mengizinkannya.
Bagaimana menguji urutan secara nyata?
- Kirim versi 2 sebelum versi 1.
- Kirim dua versi bersamaan dari koneksi berbeda.
- Ulangi event lama setelah state terbaru tersimpan.
- Hilangkan satu sequence lalu kirim sequence berikutnya.
- Restart konsumen saat buffer berisi data.
- Verifikasi status, audit, dan rekonsiliasi setelah setiap skenario.
Gunakan sample payload yang tidak hanya melewati happy path agar kesalahan urutan terlihat sebelum production.
Apa yang perlu terlihat bagi operator?
Operator perlu melihat entity, versi diterima, versi saat ini, alasan penolakan atau penundaan, dan tindakan aman berikutnya. Jangan meminta mereka menebak dari stack trace. Ukur gap yang belum selesai dan usia event tertunda, lalu eskalasi berdasarkan dampak bisnis.
Artikel ini menjelaskan pola umum dan tidak menyatakan mekanisme internal NitroNet. Platform workflow dapat membantu memvisualkan jalur versi lama, konflik, atau rekonsiliasi. Bila menilai NitroNet, mulai dari kebutuhan nyata tim dan uji dengan urutan yang sengaja diacak.
Gunakan lifecycle order dengan state dibuat, dibayar, diproses, dikirim, dan selesai. Beri setiap perubahan event ID serta versi. Lalu acak urutan secara sengaja untuk melihat apakah consumer menjaga aturan domain atau hanya menerima event terakhir yang tiba.
- Kirim state dibayar sebelum dibuat dan tentukan apakah ditahan, ditolak, atau memicu pembacaan ulang.
- Kirim diproses versi tiga lalu dibayar versi dua dan pastikan state tidak bergerak mundur.
- Kirim event versi sama dengan payload berbeda untuk mendeteksi producer yang melanggar kontrak.
- Hilangkan versi empat lalu kirim versi lima dan lihat bagaimana gap terlihat bagi operator.
- Ulangi event dikirim setelah selesai tanpa menghasilkan notifikasi atau efek bisnis kedua.
- Jalankan dua consumer paralel untuk entity sama dan uji perlindungan terhadap race condition.
- Ubah clock producer tetapi pertahankan sequence agar order tidak bergantung pada timestamp mesin.
- Jalankan rekonsiliasi terhadap state sumber setelah semua event untuk membuktikan hasil akhir.
Setiap hasil perlu memiliki alasan yang dapat dipahami operator: stale, duplicate, gap, conflict, atau invalid transition. Jangan membuang event lama tanpa jejak bila perubahan mungkin sah. Bila urutan tidak dapat ditentukan secara otomatis, alihkan konflik bernilai tinggi kepada pemilik domain daripada memilih berdasarkan waktu kedatangan.
Gunakan simulasi tiga event untuk satu entitas: dibuat, diperbarui, lalu dibatalkan. Kirim dalam semua urutan yang mungkin, ulangi salah satunya, dan sisipkan jeda melewati batas toleransi. Hasil akhir harus sama bila aturan domain menyatakan urutan logis yang sama. Bila tidak, dokumentasikan alasan serta tindakan rekonsiliasi. Pisahkan waktu kejadian, waktu producer mencatat, dan waktu sistem menerima karena ketiganya menjawab pertanyaan berbeda. Nomor versi atau sequence per entitas biasanya lebih kuat daripada timestamp yang jamnya dapat meleset.