<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Felix blog</title>
    <link>https://getfelix.dev/blog/</link>
    <description>Notes from building Felix: how it works, why it is built the way it is, and what testing it has turned up.</description>
    <language>en</language>
    <atom:link href="https://getfelix.dev/blog/feed.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Five weeks, 562 commits: Felix from 0.5.0 to 0.6.0</title>
      <link>https://getfelix.dev/blog/felix-0-5-to-0-6.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/felix-0-5-to-0-6.html</guid>
      <pubDate>Sat, 24 Oct 2026 00:00:00 +0000</pubDate>
      <description>What we found, fixed and added between Felix 0.5.0 and 0.6.0: the bugs that shared one shape, the ways we found them, the features that apps asked for and why, and what building it taught us.</description>
    </item>
    <item>
      <title>Even overall, lopsided per stream</title>
      <link>https://getfelix.dev/blog/even-overall-lopsided.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/even-overall-lopsided.html</guid>
      <pubDate>Fri, 23 Oct 2026 00:00:00 +0000</pubDate>
      <description>Felix placement kept every broker&#39;s leader count near the cluster-wide share, and a single stream could still land 1/1/10 with all its writes on one broker; this is how placement now spreads each stream&#39;s leaders too.</description>
    </item>
    <item>
      <title>Fast, without losing messages</title>
      <link>https://getfelix.dev/blog/fast-without-losing-messages.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/fast-without-losing-messages.html</guid>
      <pubDate>Fri, 23 Oct 2026 00:00:00 +0000</pubDate>
      <description>How Felix answers a fsynced publish in a third of a millisecond, writes at the disk&#39;s full rate under load, and slows publishers down instead of dropping their messages.</description>
    </item>
    <item>
      <title>Before you loosen the timeout, run the old commit</title>
      <link>https://getfelix.dev/blog/before-you-loosen-the-timeout.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/before-you-loosen-the-timeout.html</guid>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <description>Intermittent failures in Felix&#39;s cluster tests kept turning out to be real bugs in the broker, so before loosening a timeout I now run the test against a commit from before the suspect change; three cases show what that finds.</description>
    </item>
    <item>
      <title>Acknowledged, then forgotten: a crash under periodic fsync</title>
      <link>https://getfelix.dev/blog/acknowledged-then-forgotten.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/acknowledged-then-forgotten.html</guid>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <description>Under Felix&#39;s default periodic fsync, a crashed broker could come back missing records it had acknowledged while the cluster still counted it as caught up; this is how review and the TLA+ model found it on the follower and leader sides, and what the fix costs.</description>
    </item>
    <item>
      <title>How we catch a 1% regression</title>
      <link>https://getfelix.dev/blog/catching-a-one-percent-regression.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/catching-a-one-percent-regression.html</guid>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <description>Felix&#39;s rule is that a release must not be measurably slower than the one before it; this is how same-runner A/B runs, a Welch&#39;s t-test and throwaway bisect PRs in GitHub Actions find a 1-2% loss, and why a single benchmark run can&#39;t.</description>
    </item>
    <item>
      <title>The follower that forgot</title>
      <link>https://getfelix.dev/blog/the-follower-that-forgot.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/the-follower-that-forgot.html</guid>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <description>On an idle shard nothing ships, so a leader never learned that a follower had lost its disk; this is how a storage identity per data directory fixed that, and why it changes only when a directory may hold less than its peers were told.</description>
    </item>
    <item>
      <title>Our model said everything passed. It was checking nothing.</title>
      <link>https://getfelix.dev/blog/checking-nothing.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/checking-nothing.html</guid>
      <pubDate>Fri, 16 Oct 2026 00:00:00 +0000</pubDate>
      <description>Felix checks 107 TLA+ configurations in CI; this is about three times a passing check meant nothing, and the twin configurations, reachability checks and spec pairing we use to catch it.</description>
    </item>
    <item>
      <title>One slow subscriber shouldn&#39;t slow anyone else</title>
      <link>https://getfelix.dev/blog/one-slow-subscriber.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/one-slow-subscriber.html</guid>
      <pubDate>Fri, 16 Oct 2026 00:00:00 +0000</pubDate>
      <description>How Felix keeps one slow subscriber from holding up publishers or other readers, and how a 2% single-publisher loss came from where the feeder gave back a subscriber&#39;s byte budget.</description>
    </item>
    <item>
      <title>The data came back</title>
      <link>https://getfelix.dev/blog/the-data-came-back.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/the-data-came-back.html</guid>
      <pubDate>Thu, 15 Oct 2026 00:00:00 +0000</pubDate>
      <description>Deleting a Felix stream or cache and creating one with the same name could bring back the old one&#39;s data; this is how incarnations fixed it, and how we kept control-plane members on different releases from storing different answers during the rollout.</description>
    </item>
    <item>
      <title>Point your Kafka client at Felix</title>
      <link>https://getfelix.dev/blog/point-your-kafka-client-at-felix.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/point-your-kafka-client-at-felix.html</guid>
      <pubDate>Mon, 28 Sep 2026 00:00:00 +0000</pubDate>
      <description>Felix brokers speak enough of the Kafka wire protocol for Kafka producers and partition-assigning consumers to use durable Felix streams; this is how a Kafka request becomes a Felix operation, how idempotent sequences survive a failover, and exactly where compatibility stops.</description>
    </item>
    <item>
      <title>Ten parcels, one envelope: Linux UDP GSO and Felix&#39;s MTU cap</title>
      <link>https://getfelix.dev/blog/ten-parcels-one-envelope.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/ten-parcels-one-envelope.html</guid>
      <pubDate>Sun, 27 Sep 2026 00:00:00 +0000</pubDate>
      <description>Raising Felix&#39;s QUIC MTU on Linux stalled delivery for good, because UDP GSO turns ten packets into one datagram the kernel refuses and quinn never falls back; this is how we found it, why the cap is 6,550, and why 4,096 is the default.</description>
    </item>
    <item>
      <title>Introducing Felix: one log for streams, caches and counters</title>
      <link>https://getfelix.dev/blog/introducing-felix.html</link>
      <guid isPermaLink="true">https://getfelix.dev/blog/introducing-felix.html</guid>
      <pubDate>Sat, 26 Sep 2026 00:00:00 +0000</pubDate>
      <description>What Felix is, how a publish travels from a client to disk to every subscriber, why it is built that way, and how to run it on your laptop in five minutes.</description>
    </item>
  </channel>
</rss>
