GoFlowQ

Problem framing

Background jobs look simple until a worker dies halfway through a task, a retry runs twice, or the queue fills with work nobody owns anymore. GoFlowQ is my small queue runtime for those cases.

It is not trying to replace RabbitMQ. It is a place to implement the mechanics directly: leases, retries, dead letters, stuck job detection, and clean worker shutdown.

Design constraints

• Keep scheduling readable.
• Store enough metadata to explain why a job is running, delayed, retried, or dead.
• Treat retries as load, not magic.
• Make shutdown boring. Workers should leave the system in a state you can explain.

Current direction

I am using it to compare Postgres-backed queues with broker-backed systems. The interesting parts are fairness, visibility, idempotency, and what "at least once" delivery costs once application code gets involved.