<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Backends on Nalar</title>
    <link>https://nalar.dev/backend/</link>
    <description>Recent content in Backends 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/backend/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Idempotency Keys for Safe API Retries</title>
      <link>https://nalar.dev/backend/idempotency-keys-safe-api-retries/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/backend/idempotency-keys-safe-api-retries/</guid>
      <description>&lt;p&gt;Retries are essential in distributed systems. Networks fail, clients time out, load balancers reset connections, and responses sometimes disappear after a server has already committed a write.&lt;/p&gt;&#xA;&lt;p&gt;The dangerous case is a retry of a non-idempotent operation. If a client sends &lt;code&gt;POST /orders&lt;/code&gt;, times out, and sends the same request again, the server may create two orders even though the user intended one.&lt;/p&gt;&#xA;&lt;p&gt;An idempotency key gives the client a stable identifier for one logical operation. The server remembers the result associated with that key and can return the same result when the request is retried.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Liveness and Readiness Health Checks for Backend Services</title>
      <link>https://nalar.dev/backend/liveness-readiness-health-checks/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/backend/liveness-readiness-health-checks/</guid>
      <description>&lt;p&gt;Health endpoints look simple, but their semantics directly affect how a production platform routes traffic and restarts applications. A poorly designed check can turn a temporary database slowdown into a restart loop or send requests to an instance that has not finished initializing.&lt;/p&gt;&#xA;&lt;p&gt;The most useful model separates two questions:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;Liveness:&lt;/strong&gt; Is this process still capable of running?&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Readiness:&lt;/strong&gt; Should this instance receive new traffic right now?&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Those questions sound similar, but they should usually have different answers and different failure behavior.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
