The retry that doesn't need a queue

You're calling an API that's flaky. Not down: flaky. One call in fifty returns a 503 or just hangs. You need retries with backoff. Path most teams take: a queue, a worker process, a retry table, a dead-letter, a dashboard. A week of work, and now there's a queue to monitor.

You add retry_count: 5 and retry_delay: 2 to the curl request. libcurl, underneath, does exactly what you'd hand-write: try, wait two seconds, try, wait two seconds: until it succeeds or runs out. Submit as mode: "async" and the whole thing runs in the background; the job's status moves through Pending, Running, Completed or Failed. List, inspect, or cancel from another URL.

No Redis. No worker. No DLQ. A request with two extra fields.

Retries are a parameter, not a system.