100,000 cached JSON sessions repeat the exact same field names—and an in-memory queue drops jobs if a worker crashes 10ms after QPOP.
A worker can crash after removing a notification from an in-memory queue but before applying the work. The notification is gone; the durable job must remain recoverable.
This example keeps the job in SQLite and uses Spedo only for dispatch notifications. It demonstrates a recovery boundary, not a durable message broker.
Run the example
From a Spedo source checkout, with Docker Compose and Python 3 available:
docker compose up --build -d spedo
SPEDO_HOST=127.0.0.1 SPEDO_PORT=6380 \
python3 examples/transient_idempotent_job_accelerator.py
The Python script uses only the standard library. It creates a temporary SQLite database and UUID-namespaced queue keys; it does not flush the server.
Follow the crash and replay
- Insert three pending jobs into SQLite.
- Send copies through Spedo using QPUSH.
- Remove a notification using QPOP, then simulate a worker stopping before committing the job.
- Find the still-pending SQLite row and enqueue it again.
- Record the sample effect and mark the job processed in one SQLite transaction. A duplicate delivery does not create a second sample effect.
SQLite remains the source of truth throughout. The in-memory queue accelerates dispatch and can be rebuilt from pending rows.
What the example does not guarantee
The sample effect is a row in the same SQLite database. Sending an email or making an HTTP request is outside that transaction: use a receiver-supported idempotency key or another explicit delivery contract. A successful QPOP alone never means that the business operation completed.
Spedo runs as a single-node RESP service in this example. Compare the failure and recovery behavior your application needs before choosing its queue or cache boundary.
Project, source and runnable examples:
https://spedo.dev?utm_source=dev-to&utm_medium=social&utm_campaign=spedo-launch&utm_content=post-26
Top comments (0)