<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Asynclay]]></title><description><![CDATA[Learn how to run reliable background HTTP jobs in Node.js without managing Redis or workers, using scheduled execution, retries, and Asynclay.]]></description><link>https://asynclay.hashnode.dev</link><image><url>https://cdn.hashnode.com/uploads/logos/6ac9ae130acaac6e665409ed/0571a30c-6199-4fc1-9308-e2dc91600aed.webp</url><title>Asynclay</title><link>https://asynclay.hashnode.dev</link></image><generator>RSS for Node</generator><lastBuildDate>Thu, 15 Oct 2026 11:47:47 GMT</lastBuildDate><atom:link href="https://asynclay.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[I didn't want Redis + workers just to run an HTTP request later]]></title><description><![CDATA[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 ]]></description><link>https://asynclay.hashnode.dev/background-jobs-nodejs-without-redis</link><guid isPermaLink="true">https://asynclay.hashnode.dev/background-jobs-nodejs-without-redis</guid><category><![CDATA[Node.js]]></category><category><![CDATA[backend]]></category><category><![CDATA[PostgreSQL]]></category><category><![CDATA[SaaS]]></category><category><![CDATA[webdev]]></category><dc:creator><![CDATA[David Maia]]></dc:creator><pubDate>Sat, 10 Oct 2026 03:28:31 GMT</pubDate><content:encoded><![CDATA[<p>A common requirement in backend applications sounds simple:</p>
<p>"Do this later."</p>
<p>Maybe it's sending an email, processing an order, calling another service, generating something asynchronously or retrying a failed operation.</p>
<p>But the architecture can quickly become:</p>
<p><code>API → Redis → Queue → Worker → Retry Logic → Monitoring</code></p>
<p>There's nothing wrong with that architecture. For complex background processing, it's often exactly what you want.</p>
<p>But I started wondering about the simpler case.</p>
<p>What if the job is already representable as an HTTP request?</p>
<p>That's the idea behind a project I've been building called <strong>Asynclay</strong>.</p>
<p>The model is intentionally narrow:</p>
<p><code>application → Asynclay → HTTP endpoint</code></p>
<p>The application submits a target URL, payload and optional execution time.</p>
<p>Asynclay persists the job, executes it independently, retries failures and records what happened.</p>
<p>Building it led me much deeper into distributed systems than I expected.</p>
<p>The dispatcher uses PostgreSQL <code>FOR UPDATE SKIP LOCKED</code> to allow multiple instances to claim work without normally processing the same job concurrently.</p>
<p>Jobs use leases so a worker dying halfway through execution doesn't leave them stuck forever.</p>
<p>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.</p>
<p>Retries use backoff and failed executions remain observable.</p>
<p>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.</p>
<p>The result is deliberately not an alternative to every queue or workflow system.</p>
<p>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.</p>
<p>The use case I'm interested in is narrower:</p>
<p><strong>"I have an HTTP endpoint. Execute it later and make sure failures are retried."</strong></p>
<p>I'm reaching the stage where feedback from actual developers is more useful than adding another feature.</p>
<p>Asynclay is available here:</p>
<p><a href="https://asynclay.com/">Asynclay</a></p>
<p>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.</p>
]]></content:encoded></item></channel></rss>