商店網絡中斷時，如何為逆向自動售貨機的回收事件排隊

A return machine in a supermarket is a small edge device with a bad network. Shoppers do not wait for your cloud. If the uplink blips, the machine still has to accept a bottle, print a receipt, and remember that event until the link is back.

This note is the shape of that queue, not a product pitch.

What has to survive offline

Each accepted container is one event, not a row you update in place. A useful payload is small and idempotent:

{
  "event_id": "01J9…",
  "device_id": "store-14-rvm-2",
  "accepted_at": "2026-10-26T12:04:11Z",
  "material": "pet",
  "barcode": "9300675000000",
  "session_id": "s-8841",
  "scheme": "deposit"
}

event_id is generated on the device (ULID or UUIDv7). The cloud treats a repeat of the same id as a no-op. That matters because the store Wi-Fi will deliver the same batch twice.

Local queue

Keep an append-only log on disk, not in memory:

Validate the container (barcode or vision result) before you enqueue. A rejected item is not an event.
Append the event and fsync. The receipt printer should run only after that write succeeds. Otherwise a power cut prints a voucher the cloud will never see.
A worker drains the log when the uplink is healthy. Send batches of a few dozen, in accepted_at order, with the last acked event_id as a cursor.
The server acks ids, not "the whole request". Drop only the acked prefix. Leave the rest for the next attempt.

Clock skew is normal. Do not sort the fleet by device clock alone. Store both accepted_at (device) and received_at (server), and let settlement use the scheme's rules.

What not to do

Do not hold the shopper UI on an HTTP call to the cloud. Recognition and the receipt are local. Sync is background.
Do not key the event on barcode + timestamp in seconds. Two cans in the same second collide, and a retry looks like a new return.
Do not compact or delete the on-device log until the ack is durable. A full disk should refuse new returns with a clear message, not drop history.

Vision sits beside this, not inside it

If the machine uses a camera to tell PET from a look-alike, that score belongs on the event as evidence (vision_label, confidence), but the accept/reject decision should already be made before enqueue. Re-running the model in the cloud is for audits, not for changing a receipt the shopper already holds.

Operators who run a fleet of these machines end up with the same three questions: is the device online, how far behind is its cursor, and which sessions never got an ack. That is a queue-depth problem more than a recycling problem.

I work on this class of system at RECYNEX. A higher-level description of the return flow (not the queue) is on our site: https://www.recynex.com/news/what-is-a-reverse-vending-machine/