<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Architecture on Nalar</title>
    <link>https://nalar.dev/tags/architecture/</link>
    <description>Recent content in Architecture on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 01 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/architecture/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Designing Stateless Web Services for Horizontal Scaling</title>
      <link>https://nalar.dev/stateless-services-horizontal-scaling/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/stateless-services-horizontal-scaling/</guid>
      <description>&lt;p&gt;Horizontal scaling adds application replicas instead of making one machine larger. The load balancer can send each request to any healthy instance, which only works reliably when instances do not depend on unique local state.&lt;/p&gt;&#xA;&lt;p&gt;&amp;ldquo;Stateless&amp;rdquo; does not mean the application has no state. It means durable or shared state lives outside an individual process so any replica can continue serving the workload.&lt;/p&gt;&#xA;&lt;h2 id=&#34;identify-hidden-local-state&#34;&gt;Identify hidden local state&lt;/h2&gt;&#xA;&lt;p&gt;A service may appear stateless while depending on:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Evolving APIs Without Breaking Clients</title>
      <link>https://nalar.dev/evolving-apis-without-breaking-clients/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/evolving-apis-without-breaking-clients/</guid>
      <description>&lt;p&gt;An API is not only an HTTP path or function signature. It is a contract about syntax, semantics, timing, errors, ordering, defaults, and lifecycle.&lt;/p&gt;&#xA;&lt;p&gt;Breaking changes often happen because a server remains syntactically compatible while changing one of those less-visible assumptions.&lt;/p&gt;&#xA;&lt;p&gt;Safe API evolution starts by identifying what clients can reasonably depend on and designing changes that allow old and new versions to coexist.&lt;/p&gt;&#xA;&lt;h2 id=&#34;compatibility-has-multiple-dimensions&#34;&gt;Compatibility has multiple dimensions&lt;/h2&gt;&#xA;&lt;p&gt;A change can preserve JSON shape and still break clients.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Feature Flags Without Long-Lived Technical Debt</title>
      <link>https://nalar.dev/feature-flags-without-technical-debt/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/feature-flags-without-technical-debt/</guid>
      <description>&lt;p&gt;Feature flags decouple code deployment from feature release. A team can deploy dormant code, enable it for internal users, roll it out gradually, and disable it without rebuilding the application.&lt;/p&gt;&#xA;&lt;p&gt;The cost is hidden control flow. Every long-lived flag creates another possible system configuration, and interacting flags multiply those configurations quickly.&lt;/p&gt;&#xA;&lt;p&gt;The engineering goal is therefore not &amp;ldquo;use flags everywhere.&amp;rdquo; It is to make each flag temporary, observable, and owned.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
