distributed job queue

what it is

a durable, sidekiq-style job queue written in c++. clients enqueue jobs over tcp, workers claim them, and everything lives in sqlite.

TODO: why build it, and why sqlite.

delivery: at-least-once, with leases

workers claim jobs with a lease. if a worker disappears, the lease expires and the job goes back to the pool.

TODO: lease length, what "claim" looks like in sql, why at-least-once and not exactly-once.

letting sqlite do the locking

concurrency safety is handed to sqlite's file locking. zero double-claims across 32 threads and 5,000+ jobs.

TODO: how the claim query works, and how you tested for double-claims.

the bottleneck wasn't the network

per-commit fsync, not networking or threads, capped throughput: ~150 jobs/s fully durable vs ~1,700–2,800 relaxed (11–18x).

TODO: how you found it, what "relaxed" means here, and the tradeoff you picked.

two bugs worth writing down

• a query-planner regression, fixed with explain query plan
• a stale-lease race, fixed with a fencing token

TODO: what each one looked like when it happened.

kill -9

sigkill mid-load across 10+ restarts, with zero acknowledged jobs lost.

TODO: the test harness, and what "acknowledged" guarantees.