I didn't want Redis + workers just to run an HTTP request later

David — Wed, 30 Sep 2026 16:00:11 +0000

A common requirement in backend applications sounds simple:

"Do this later."

Maybe it's sending an email, processing an order, calling another service, generating something asynchronously or retrying a failed operation.

But the architecture can quickly become:

API → Redis → Queue → Worker → Retry Logic → Monitoring

There's nothing wrong with that architecture. For complex background processing, it's often exactly what you want.

But I started wondering about the simpler case.

What if the job is already representable as an HTTP request?

That's the idea behind a project I've been building called Asynclay.

The model is intentionally narrow:

application → Asynclay → HTTP endpoint

The application submits a target URL, payload and optional execution time.

Asynclay persists the job, executes it independently, retries failures and records what happened.

Building it led me much deeper into distributed systems than I expected.

The dispatcher uses PostgreSQL FOR UPDATE SKIP LOCKED to allow multiple instances to claim work without normally processing the same job concurrently.

Jobs use leases so a worker dying halfway through execution doesn't leave them stuck forever.

Delivery is at-least-once rather than pretending exactly-once HTTP delivery exists, so targets receive a stable job identifier they can use for idempotency.

Retries use backoff and failed executions remain observable.

And because users can provide arbitrary target URLs, the executor also needs to treat every outbound request as potentially hostile — including SSRF, private IP ranges, DNS changes and redirects.

The result is deliberately not an alternative to every queue or workflow system.

If you need complex workflows, CPU-heavy processing, custom workers or complete control over infrastructure, tools such as BullMQ and dedicated workers make much more sense.

The use case I'm interested in is narrower:

"I have an HTTP endpoint. Execute it later and make sure failures are retried."

I'm reaching the stage where feedback from actual developers is more useful than adding another feature.

Asynclay is available here:

Asynclay — Schedule HTTP Jobs & Webhooks With Automatic Retries

Schedule delayed HTTP callbacks with automatic retries, idempotency and full execution logs through a simple REST API. Free tier included.

asynclay.com

I'd particularly like to hear where you think this model breaks down — or what would prevent you from trusting an external service with background execution.

DEV Community: David

I didn't want Redis + workers just to run an HTTP request later

Asynclay — Schedule HTTP Jobs & Webhooks With Automatic Retries