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