Queues, Streams, and Exactly-once Patterns

Let workers take jobs through their local Swytch endpoint while sharing a queue across workloads. Choose a list for simple destructive reads or a stream when work needs an acknowledgement and pending-entry workflow.

A successful list pop removes the item. If the worker then crashes before finishing the job, the queue does not put it back automatically. Streams let the application track pending work and reclaim it after a consumer failure.

Start with lists or streams. Configure a storage tier if losing every in-memory holder must not erase pending work.

Swytch’s transaction machinery coordinates competing destructive operations on shared state. That guarantee is about the data operation. It does not atomically include an email, payment, or write to another database.

Give external actions a stable job identifier and make retries idempotent. If a connection drops after an operation commits, the client may not know whether it completed. Retrying blindly can perform another operation.

See exactly-once semantics for that boundary and partition behavior before distributing workers across unreliable links.