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