<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Systems-Design on Mad Blog</title>
    <link>/tags/systems-design/</link>
    <description>Recent content in Systems-Design on Mad Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-GB</language>
    <managingEditor>madking.direct@gmail.com (Mad King)</managingEditor>
    <webMaster>madking.direct@gmail.com (Mad King)</webMaster>
    <lastBuildDate>Wed, 17 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="/tags/systems-design/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Message Queues Gone Wrong: When to Reach for RabbitMQ and When Kafka Will Eat Your Lunch</title>
      <link>/posts/rabbitmq-vs-kafka/</link>
      <pubDate>Wed, 17 Jun 2026 00:00:00 +0000</pubDate>
      <author>madking.direct@gmail.com (Mad King)</author>
      <guid>/posts/rabbitmq-vs-kafka/</guid>
      
      <description>&lt;p&gt;Every system eventually needs to talk to itself. Order here, process there, notify someone, retry on failure, repeat. Messaging is how you stitch services together without hardcoding them into each other.&lt;/p&gt;
&lt;p&gt;Two names come up every time: RabbitMQ and Kafka.&lt;/p&gt;
&lt;p&gt;Both move messages. Both decouple producers from consumers. Both are &amp;ldquo;just queues&amp;rdquo; until you&amp;rsquo;ve built something on top of them and realised they&amp;rsquo;re not.&lt;/p&gt;
&lt;p&gt;This is how to pick between them. And more importantly, how to stop picking the wrong one out of habit.&lt;/p&gt;</description>
      
    </item>
    
    <item>
      <title>The Multi-Threading Fallacy: Why Management Keeps Misunderstanding System Design</title>
      <link>/posts/multi-threading-fallacy/</link>
      <pubDate>Tue, 02 Jun 2026 00:00:00 +0000</pubDate>
      <author>madking.direct@gmail.com (Mad King)</author>
      <guid>/posts/multi-threading-fallacy/</guid>
      
      <description>&lt;p&gt;Someone in a meeting somewhere is about to say: &lt;em&gt;&amp;ldquo;let&amp;rsquo;s add multi-threading — it&amp;rsquo;ll speed things up.&amp;rdquo;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Every senior engineer just flinched. Because that sentence has killed more projects than bad requirements, understaffing, and legacy codebases combined.&lt;/p&gt;
&lt;p&gt;Here&amp;rsquo;s the problem: threading is sold as a performance technique. In practice it&amp;rsquo;s a &lt;strong&gt;correctness&lt;/strong&gt; technique used for a very narrow set of problems. And the number of times it actually delivers on its performance promise is small enough to count on one hand.&lt;/p&gt;</description>
      
    </item>
    
  </channel>
</rss>
