<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Sagas on FlowChassis.com</title>
    <link>https://flowchassis.com/tags/sagas/</link>
    <description>Recent content in Sagas 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/tags/sagas/index.xml" rel="self" type="application/rss+xml" />
    <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>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>
  </channel>
</rss>
