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

  1. Insert three pending jobs into SQLite.
  2. Send copies through Spedo using QPUSH.
  3. Remove a notification using QPOP, then simulate a worker stopping before committing the job.
  4. Find the still-pending SQLite row and enqueue it again.
  5. 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