<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Job Queues on ukue.com</title>
    <link>https://ukue.com/tags/job-queues/</link>
    <description>Recent content in Job Queues on ukue.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 06 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://ukue.com/tags/job-queues/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A Job Queue in One SQLite File: ukue 0.1 Lets Small Teams Skip Redis</title>
      <link>https://ukue.com/a-job-queue-in-one-sqlite-file-ukue-0.1-lets-small-teams-skip-redis/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/a-job-queue-in-one-sqlite-file-ukue-0.1-lets-small-teams-skip-redis/</guid>
      <description>&lt;p&gt;Sooner or later every web app needs to do something outside the request. Send the welcome email after the user has seen the page. Resize the photo while they carry on. Retry the webhook when the other side is down. The standard way to do that is a job queue, and the standard way to get a job queue is to run Redis or RabbitMQ next to your app.&lt;/p&gt;&#xA;&lt;p&gt;ukue 0.1 puts the whole queue in one file instead. It&amp;rsquo;s a SQLite database with a documented layout, and it holds every queue, every waiting job, every retry and every job that failed for good. A Go program imports ukue as a library. Everything else uses the one small &lt;code&gt;ukue&lt;/code&gt; binary, which runs a script for each job or serves a small HTTP API.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How the ukue Job Queue Was Tested: 250 Killed Workers, 0 Lost Jobs</title>
      <link>https://ukue.com/how-the-ukue-job-queue-was-tested-250-killed-workers-0-lost-jobs/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/how-the-ukue-job-queue-was-tested-250-killed-workers-0-lost-jobs/</guid>
      <description>&lt;p&gt;A job queue makes one promise above all others: a job that was added runs, even if the machine has a bad day. So the most important tests for ukue don&amp;rsquo;t check the happy path. They kill workers in the middle of their work and look at what&amp;rsquo;s left.&lt;/p&gt;&#xA;&lt;p&gt;The tests run on every change to the code, on Linux and macOS, and the recorded output is published with the code in &lt;a href=&#34;https://github.com/ukue-queue/ukue/tree/main/test/results&#34;&gt;test/results&lt;/a&gt;. The numbers below come from the recorded run, on a two-core cloud machine.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What Is a Job Queue? Background Jobs, Retries and Dead Letters Explained</title>
      <link>https://ukue.com/what-is-a-job-queue-background-jobs-retries-and-dead-letters-explained/</link>
      <pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ukue.com/what-is-a-job-queue-background-jobs-retries-and-dead-letters-explained/</guid>
      <description>&lt;p&gt;A job queue is a to-do list for software. When something has to happen but doesn&amp;rsquo;t have to happen right now, a program writes it on the list and moves on. A separate worker takes items off the list and does them. That&amp;rsquo;s the whole idea, and almost every web app ends up needing it.&lt;/p&gt;&#xA;&lt;p&gt;Take a sign-up form. When a user signs up, the app has to save the account, send a welcome email, and maybe tell the sales team&amp;rsquo;s CRM. Saving the account is quick. Talking to a mail server can take seconds, and it might be down. Making the user stare at a spinner while that happens is a poor trade, so the app saves the account, adds &amp;ldquo;send a welcome email to Dana&amp;rdquo; to a job queue, and shows the next page at once. A worker sends the email a moment later.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
