Saat jaringan toko terputus, pilihan bisnisnya bukan sekadar “retry atau gagal”. POS mungkin tetap harus melayani penjualan sementara inventory pusat tidak dapat dikonfirmasi. Sistem perlu aturan eksplisit tentang transaksi offline, stok lokal, urutan sinkronisasi, konflik, dan rekonsiliasi ketika koneksi kembali.
Apa arti “stok terjaga”?
Inventory dapat merepresentasikan on-hand, reserved, available-to-promise, in-transit, rusak, atau stok per lokasi. POS membutuhkan subset yang relevan untuk keputusan penjualan. Mengirim satu angka stock tanpa definisi dapat membuat sistem tampak sinkron padahal masing-masing menghitung hal berbeda.
Tentukan sumber kebenaran per state dan toleransi staleness. Inventory pusat mungkin otoritatif untuk on-hand jaringan, sementara POS menyimpan provisional sale lokal selama offline. Setelah tersambung, transaksi lokal harus masuk sebagai event yang dapat direkonsiliasi—bukan sekadar menimpa angka pusat dengan snapshot toko.
Pilih kebijakan penjualan offline secara sadar
| Kebijakan | Keuntungan | Risiko | Kontrol |
|---|---|---|---|
| Blokir penjualan | Menghindari oversell offline | Kehilangan layanan | Fallback dan komunikasi |
| Izinkan semua | Operasi terus berjalan | Oversell dan rekonsiliasi tinggi | Limit serta review |
| Kuota lokal | Menyeimbangkan layanan dan risiko | Kuota dapat usang | Refresh dan threshold |
| Aturan per SKU | Sesuai karakter barang | Konfigurasi lebih kompleks | Owner dan audit aturan |
Platform integrasi tidak berwenang memilih kebijakan ini. Retail owner perlu menilai nilai barang, kecepatan perputaran, alternatif fulfillment, konsekuensi oversell, dan kewajiban pelanggan. Integrasi kemudian menegakkan serta merekam keputusan tersebut.
Kontrak event untuk replay yang aman
Setiap penjualan perlu event ID stabil yang tidak berubah saat dikirim ulang, ID toko/terminal, waktu kejadian dan waktu diterima, item, kuantitas, satuan, serta jenis operasi. Retur, void, koreksi, dan transfer jangan disamarkan sebagai penjualan negatif tanpa kontrak yang jelas. Sertakan versi schema agar consumer mengetahui bentuk data.
- Gunakan idempotency key dari identitas transaksi, bukan UUID baru pada setiap retry.
- Pertahankan urutan per aggregate yang membutuhkannya, bukan memaksakan urutan global.
- Simpan event secara durable di sisi toko sebelum mengakui transaksi bila dibutuhkan bisnis.
- Bedakan error permanen karena data dengan error sementara karena koneksi.
- Jangan memasukkan data pembayaran sensitif ke log integrasi.
Apa yang terjadi ketika jaringan kembali?
- Bangun koneksi.
Verifikasi identity agent dan kesehatan jalur sebelum menguras buffer.
- Atur laju.
Kirim backlog dengan rate yang tidak menenggelamkan inventory atau mengganggu trafik baru.
- Dedup.
Reservasi key atomik dan pastikan retry transaksi lama tidak menciptakan pengurangan kedua.
- Terapkan versi.
Tolak event lama yang bertentangan atau route ke jalur rekonsiliasi.
- Rekonsiliasi.
Bandingkan total transaksi, adjustment, dan posisi stok per lokasi setelah backlog selesai.
Prioritas backlog perlu diputuskan. Mengirim transaksi lama selalu lebih dulu menjaga urutan, tetapi event baru mungkin lebih sensitif waktu. Jika alur diparalelkan, pastikan aturan inventory mampu menangani urutan berbeda. Rate limit ingress dan throttle pemrosesan memiliki fungsi berbeda: yang pertama dapat menolak request, yang kedua mengatur jadwal pekerjaan.
Kontrol operasional yang perlu dipantau
Monitor umur pesan tertua, jumlah backlog per toko, tingkat retry, duplicate yang ditahan, error kontrak, serta selisih rekonsiliasi. Alarm harus menunjuk owner toko, jaringan, integrasi, atau inventory berdasarkan jenis masalah. Dashboard “agent online” saja tidak membuktikan semua transaksi sudah sampai.
Uji dengan memutus jaringan secara terkendali: lakukan transaksi, retry, restart agent, reconnect, dan kirim burst backlog. Verifikasi tidak ada data hilang atau diterapkan dua kali. Uji juga retensi: bila outage lebih lama dari kemampuan buffer, sistem harus menandai gap dan memicu prosedur manual, bukan mengklaim sinkronisasi sukses.
Menerapkan pola melalui NitroNet
Kapasitas normal belum tentu cukup untuk backlog beberapa jam ditambah trafik baru. Perkirakan jumlah event per toko selama outage, ukuran rata-rata, ruang buffer, waktu drain yang diinginkan, serta kapasitas aman inventory. Gunakan hasil uji, bukan asumsi vendor. Tentukan prioritas bila retensi atau storage mendekati batas dan pastikan operator mengetahui pesan mana yang memerlukan ekspor atau rekonsiliasi manual.
Saat menilai platform integrasi untuk skenario POS dan inventory, tim perlu menguji kemampuan mempertahankan pesan, mengendalikan laju pemulihan, mencegah duplikasi, dan memperlihatkan status kegagalan. NitroNet dapat dimasukkan ke dalam evaluasi tersebut melalui pilot terukur; batas retensi, kapasitas, dan prosedur rekonsiliasi tetap harus ditetapkan operator.
Mulailah pada satu toko dan beberapa SKU dengan data uji, ukur perilaku backlog, lalu lakukan rekonsiliasi bersama inventory owner sebelum memperluas. Baca rate limit endpoint dan biaya satu kegagalan integrasi. NitroNet menyediakan mekanisme reliability; keputusan menerima penjualan offline dan risiko stok tetap milik bisnis.