<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on TaskFused.com</title>
    <link>https://taskfused.com/posts/</link>
    <description>Recent content in Posts on TaskFused.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 18 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://taskfused.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Cache Stampede Protection With TaskFused, One Rebuild When a Busy Page Expires</title>
      <link>https://taskfused.com/cache-stampede-protection-with-taskfused-one-rebuild-when-a-busy-page-expires/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/cache-stampede-protection-with-taskfused-one-rebuild-when-a-busy-page-expires/</guid>
      <description>&lt;p&gt;A news site&amp;rsquo;s front page is built from a dozen slow queries, so it&amp;rsquo;s cached for five minutes. At the moment the cache entry expires, three hundred readers are loading the page. Every one of them misses the cache, and every one starts the same dozen queries. The database, which was fine a second ago, is suddenly doing three hundred times the work, pages time out, and the timeouts make readers reload. That&amp;rsquo;s a cache stampede, sometimes called the thundering herd.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Client Retries After a Timeout With TaskFused, the Second Request Joins the First</title>
      <link>https://taskfused.com/client-retries-after-a-timeout-with-taskfused-the-second-request-joins-the-first/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/client-retries-after-a-timeout-with-taskfused-the-second-request-joins-the-first/</guid>
      <description>&lt;p&gt;A phone app sends &amp;ldquo;import my contacts&amp;rdquo; to your server. The import takes twelve seconds, but the app gives up after ten, because that&amp;rsquo;s what its HTTP client does by default. It shows a spinner and sends the request again. Now the server is running two imports of the same contacts into the same account, and the user ends up with every contact twice.&lt;/p&gt;&#xA;&lt;p&gt;Retries like that are normal and mostly good. Networks drop replies, phones switch from Wi-Fi to mobile data, and a client that never retried would leave users stuck. The trouble is a retry that can&amp;rsquo;t tell it&amp;rsquo;s a retry. TaskFused gives the server a way to tell.&lt;/p&gt;</description>
    </item>
    <item>
      <title>First TaskFused Release Runs Duplicate Requests Once and Survives Worker Crashes</title>
      <link>https://taskfused.com/first-taskfused-release-runs-duplicate-requests-once-and-survives-worker-crashes/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/first-taskfused-release-runs-duplicate-requests-once-and-survives-worker-crashes/</guid>
      <description>&lt;p&gt;Some work gets asked for more than once. Someone double-clicks Export. A client times out and sends the request again while the first one is still running. Ten dashboards open at nine and all want last month&amp;rsquo;s report. Each copy costs the same CPU, the same API credits and the same database time as the first, and when copies overlap they can trip over each other.&lt;/p&gt;&#xA;&lt;p&gt;TaskFused 0.1 is a small Go engine that runs that work once. You name each piece of work. The first request with a name creates an operation, saved to a local SQLite file before anyone hears about it. Equal requests after that join the same operation, wait with it, and get the same result. Once the work is done, later requests get the stored result straight away.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How TaskFused Got Its Name From Fusing Duplicate Tasks Into One</title>
      <link>https://taskfused.com/how-taskfused-got-its-name-from-fusing-duplicate-tasks-into-one/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/how-taskfused-got-its-name-from-fusing-duplicate-tasks-into-one/</guid>
      <description>&lt;p&gt;To fuse is to join two things so completely that they become one. Metal fuses when it melts together. Two bones fuse as they heal. Nothing is stacked or queued; afterwards there&amp;rsquo;s a single piece where there used to be several.&lt;/p&gt;&#xA;&lt;p&gt;That&amp;rsquo;s what TaskFused does with duplicate work. Ten requests for the same report don&amp;rsquo;t become ten jobs, or one job and nine copies waiting their turn. They become one operation, with one run and one result, and all ten callers are holding it.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How TaskFused Was Tested With Killed Workers and Injected Storage Faults</title>
      <link>https://taskfused.com/how-taskfused-was-tested-with-killed-workers-and-injected-storage-faults/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/how-taskfused-was-tested-with-killed-workers-and-injected-storage-faults/</guid>
      <description>&lt;p&gt;TaskFused makes one promise above the others: work that two requests share is done once and kept safe, even when the process doing it dies. That&amp;rsquo;s easy to claim and easy to get wrong, so most of the tests try to break it. They kill real processes, make the storage fail on purpose, and drop connections at awkward moments.&lt;/p&gt;&#xA;&lt;p&gt;Every result below comes from the files in &lt;a href=&#34;https://github.com/taskfused/taskfused/tree/main/test/results&#34;&gt;test/results&lt;/a&gt;, recorded from version 0.1.0 on a two-core Linux cloud machine with Go 1.24 and SQLite 3.50.4, with every change flushed to disk. The same tests run on every push, on Linux and macOS.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Monthly Report Exports With TaskFused, Built Once When Ten Managers Click at 9am</title>
      <link>https://taskfused.com/monthly-report-exports-with-taskfused-built-once-when-ten-managers-click-at-9am/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/monthly-report-exports-with-taskfused-built-once-when-ten-managers-click-at-9am/</guid>
      <description>&lt;p&gt;On the first working day of the month, every regional manager opens the dashboard and clicks Export on last month&amp;rsquo;s sales report. The report is the same for all of them. It reads two million order rows, groups them, draws six charts and writes a PDF, which takes about forty seconds of database time. Ten clicks in the same minute means ten copies of that work, ten heavy queries fighting over the same tables, and a dashboard that crawls for everyone else.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Paid AI Calls With TaskFused, One Model Call Billed When Three Parts of an App Ask</title>
      <link>https://taskfused.com/paid-ai-calls-with-taskfused-one-model-call-billed-when-three-parts-of-an-app-ask/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/paid-ai-calls-with-taskfused-one-model-call-billed-when-three-parts-of-an-app-ask/</guid>
      <description>&lt;p&gt;A user uploads a 40-page contract and the app wants a summary. The browser asks for it when the page opens. The search indexer asks for it a few seconds later, because summaries make good snippets. And the user, impatient, hits Refresh. Three requests, one document, and each one would send the whole contract to a language model and pay for every token of it, three times.&lt;/p&gt;&#xA;&lt;p&gt;AI calls are the clearest case for doing work once. They&amp;rsquo;re slow, often ten or twenty seconds for a long document, so duplicates overlap a lot. They&amp;rsquo;re billed per token. And the answer for the same document, model and prompt doesn&amp;rsquo;t need to be made twice.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Payments and Emails With TaskFused, Using the Operation ID as the Idempotency Key</title>
      <link>https://taskfused.com/payments-and-emails-with-taskfused-using-the-operation-id-as-the-idempotency-key/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/payments-and-emails-with-taskfused-using-the-operation-id-as-the-idempotency-key/</guid>
      <description>&lt;p&gt;A shop charges a customer&amp;rsquo;s card when they confirm an order, then sends the receipt. The confirm button gets double-clicked, the request gets retried, and a worker might crash at any point. Two charges for one order is the one outcome that must never happen, and a second receipt is embarrassing.&lt;/p&gt;&#xA;&lt;p&gt;TaskFused already stops the double click and the retry from doing anything twice: they join the same operation. But it runs each operation at least once, and that leaves one gap. A worker can charge the card and then die before it saves &amp;ldquo;done&amp;rdquo;. The lease runs out, another worker takes the operation over, and that worker charges again. This post is about closing that gap.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Video Rendering Through a Deploy With TaskFused, the Job Moves to a New Worker</title>
      <link>https://taskfused.com/video-rendering-through-a-deploy-with-taskfused-the-job-moves-to-a-new-worker/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/video-rendering-through-a-deploy-with-taskfused-the-job-moves-to-a-new-worker/</guid>
      <description>&lt;p&gt;A video app turns each upload into a 1080p preview. A render takes about four minutes of CPU. Deploys happen several times a day, and every deploy restarts the render workers. With a simple job runner, a render that was three minutes in when the deploy started is just gone. The user&amp;rsquo;s preview never appears, or someone has to notice and start it again.&lt;/p&gt;&#xA;&lt;p&gt;The same render is also asked for more than once. The uploader&amp;rsquo;s browser asks for the preview, the share page asks for it when the link is opened, and the mobile app asks when it syncs. They all want the same file.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What Is Request Coalescing and Why Duplicate Work Should Share One Result</title>
      <link>https://taskfused.com/what-is-request-coalescing-and-why-duplicate-work-should-share-one-result/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://taskfused.com/what-is-request-coalescing-and-why-duplicate-work-should-share-one-result/</guid>
      <description>&lt;p&gt;Request coalescing means that when several requests ask for the same thing at the same time, the work is done once and every one of them gets the answer. The other requests don&amp;rsquo;t queue up behind the first and repeat it. They attach to it.&lt;/p&gt;&#xA;&lt;p&gt;It sounds like a cache, and it&amp;rsquo;s related, but it works at a different moment. A cache helps after the answer exists. Coalescing helps while the answer is still being made, which is exactly when duplicates hurt most: a slow report, an expensive API call, a page that a thousand visitors hit the second it expires from the cache.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
