<?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 FlowChassis.com</title>
    <link>https://flowchassis.com/posts/</link>
    <description>Recent content in Posts on FlowChassis.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 18 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://flowchassis.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>FlowChassis 0.1.0 Released as an Open Source Workflow Kernel for Go</title>
      <link>https://flowchassis.com/flowchassis-0.1.0-released-as-an-open-source-workflow-kernel-for-go/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://flowchassis.com/flowchassis-0.1.0-released-as-an-open-source-workflow-kernel-for-go/</guid>
      <description>&lt;p&gt;FlowChassis 0.1.0 is out. It is a small workflow execution kernel for Go: you describe a job as steps, and it runs them inside your own program, writes a checkpoint before and after every step, retries what fails, undoes what can&amp;rsquo;t finish, and carries on after a crash from exactly where it stopped. It is open source under the Apache License 2.0.&lt;/p&gt;&#xA;&lt;p&gt;There is no server to run and no database to set up. The whole thing is a library and one journal file. The library needs nothing outside the Go standard library, so adding it pulls in no other modules at all.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What a Workflow Execution Kernel Is and Why Sagas Need One</title>
      <link>https://flowchassis.com/what-a-workflow-execution-kernel-is-and-why-sagas-need-one/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://flowchassis.com/what-a-workflow-execution-kernel-is-and-why-sagas-need-one/</guid>
      <description>&lt;p&gt;Picture an online shop&amp;rsquo;s order code. Reserve the stock. Charge the card. Print a receipt. Book the courier. Email the customer. Five calls, five different systems, and no database transaction that spans them, because the card network and the courier don&amp;rsquo;t take part in your transactions.&lt;/p&gt;&#xA;&lt;p&gt;Most of the time all five work. The trouble is the other times. The courier&amp;rsquo;s API refuses the address after the card was charged. Or the server restarts during the charge, and nobody knows whether it went through. Each of those leaves the order half done, and half done is the worst state there is: money taken, nothing shipped, and the code that knew what to do next gone with the process.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How FlowChassis Was Tested With 240 Worker Kills and Not One Lost Order</title>
      <link>https://flowchassis.com/how-flowchassis-was-tested-with-240-worker-kills-and-not-one-lost-order/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://flowchassis.com/how-flowchassis-was-tested-with-240-worker-kills-and-not-one-lost-order/</guid>
      <description>&lt;p&gt;FlowChassis makes one main promise: whatever happens to the process, every run picks up where it stopped, and nothing it did is lost or done twice without warning. The only honest way to test that promise is to break the process, over and over, at moments nobody chose, and then check the results against something the engine can&amp;rsquo;t fake.&lt;/p&gt;&#xA;&lt;p&gt;So that&amp;rsquo;s what the tests do. This post goes through them, with the numbers from the recorded results in the &lt;a href=&#34;https://github.com/flowchassis/flowchassis/tree/main/test/results&#34;&gt;code repository&lt;/a&gt;. Every figure below comes from those files.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why the Project Is Called FlowChassis</title>
      <link>https://flowchassis.com/why-the-project-is-called-flowchassis/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://flowchassis.com/why-the-project-is-called-flowchassis/</guid>
      <description>&lt;p&gt;A car&amp;rsquo;s chassis is the frame everything else bolts onto. The engine, the wheels, the body and the seats all hang from it. You don&amp;rsquo;t see it when you look at a car, and you don&amp;rsquo;t choose a car by it. But it decides whether the car holds together on a bad road.&lt;/p&gt;&#xA;&lt;p&gt;That is the job FlowChassis does for a workflow. The flow is the work you care about: an order, a sign-up, a device update. The chassis is what carries it, and the part that keeps it in one piece when something hits.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Account Signup With FlowChassis Leaves No Half-Made Accounts</title>
      <link>https://flowchassis.com/account-signup-with-flowchassis-leaves-no-half-made-accounts/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://flowchassis.com/account-signup-with-flowchassis-leaves-no-half-made-accounts/</guid>
      <description>&lt;p&gt;Signing someone up sounds like one action. It&amp;rsquo;s usually four. You create the user record, give the account its storage, send the welcome email, and switch the account on. Each of those talks to a different system, and any of them can fail while the others have already happened.&lt;/p&gt;&#xA;&lt;p&gt;The usual result is a half-made account. The user row exists but the bucket doesn&amp;rsquo;t. Or the bucket exists, the email bounced, and nobody knows whether to try again. Someone writes a cleanup script. Then the cleanup script needs its own cleanup.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cloud Provisioning With FlowChassis Tears Down What a Failed Deploy Built</title>
      <link>https://flowchassis.com/cloud-provisioning-with-flowchassis-tears-down-what-a-failed-deploy-built/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://flowchassis.com/cloud-provisioning-with-flowchassis-tears-down-what-a-failed-deploy-built/</guid>
      <description>&lt;p&gt;Putting a site on a new server takes a handful of calls to different providers. Create the VM. Point a DNS record at it. Get a TLS certificate. Then wait until the thing answers its health check, which can take a while because VMs take time to boot.&lt;/p&gt;&#xA;&lt;p&gt;When the certificate step fails, you&amp;rsquo;re left with a VM you pay for by the hour and a DNS record pointing at it. Run that a few hundred times across a team and you get the cloud bill everyone recognises: servers nobody remembers creating.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Video Transcoding With FlowChassis Survives a Crash Without Starting Over</title>
      <link>https://flowchassis.com/video-transcoding-with-flowchassis-survives-a-crash-without-starting-over/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://flowchassis.com/video-transcoding-with-flowchassis-survives-a-crash-without-starting-over/</guid>
      <description>&lt;p&gt;Some jobs take minutes or hours. Transcoding a long video is the classic one. The usual design is a worker that picks up the job and grinds through it, and when that worker dies at 80 percent, say because a deploy restarted it, the job starts again from zero.&lt;/p&gt;&#xA;&lt;p&gt;Starting over is fine once. On a busy system with regular deploys it means the longest jobs are the ones that never finish.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Webhook Delivery With FlowChassis Backs Off Between Retries and Dead-Letters What Fails</title>
      <link>https://flowchassis.com/webhook-delivery-with-flowchassis-backs-off-between-retries-and-dead-letters-what-fails/</link>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://flowchassis.com/webhook-delivery-with-flowchassis-backs-off-between-retries-and-dead-letters-what-fails/</guid>
      <description>&lt;p&gt;If your product sends webhooks, you&amp;rsquo;ve built a small delivery system whether you meant to or not. Customers&amp;rsquo; endpoints go down, answer slowly, return errors for an hour during their own deploy, or get deleted without anyone telling you. Each event has to get there once, eventually, or end up somewhere a person can see it.&lt;/p&gt;&#xA;&lt;p&gt;The rules are well known. Retry on 5xx and timeouts, waiting longer each time. Stop on a 410 Gone. Sign every request so the receiver can trust it. Send the same delivery ID on every attempt so the receiver can drop a duplicate. And when you give up, put the event in a dead-letter queue instead of losing it.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
