<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Software Architecture on Nalar</title>
    <link>https://nalar.dev/tags/software-architecture/</link>
    <description>Recent content in Software Architecture on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 04 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/software-architecture/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Designing Failure Containment Boundaries</title>
      <link>https://nalar.dev/designing-failure-containment-boundaries/</link>
      <pubDate>Fri, 04 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/designing-failure-containment-boundaries/</guid>
      <description>&lt;p&gt;A component fails. Soon unrelated requests become slow, worker queues stop moving, and healthy features begin returning errors. The original defect may be small, but the system has allowed its effects to spread.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Failure containment&lt;/strong&gt; is the design practice of limiting how far a fault can propagate. The goal is not to prevent every failure. That is unrealistic. The goal is to make a local failure stay local enough that the rest of the system can continue useful work or fail in a controlled way.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
