<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cloud Computing on Nalar</title>
    <link>https://nalar.dev/tags/cloud-computing/</link>
    <description>Recent content in Cloud Computing 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/cloud-computing/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>Idempotent Event Consumers for At-Least-Once Delivery</title>
      <link>https://nalar.dev/idempotent-event-consumers-at-least-once-delivery/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/idempotent-event-consumers-at-least-once-delivery/</guid>
      <description>&lt;p&gt;Many queues and event brokers provide at-least-once delivery: a message that has been accepted can be delivered again when acknowledgements are lost, consumers crash, visibility timeouts expire, or the broker retries after uncertain outcomes.&lt;/p&gt;&#xA;&lt;p&gt;Duplicates are therefore not exceptional. A robust consumer should assume that the same logical event can arrive more than once.&lt;/p&gt;&#xA;&lt;h2 id=&#34;why-duplicates-happen&#34;&gt;Why duplicates happen&lt;/h2&gt;&#xA;&lt;p&gt;Consider this sequence:&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;a consumer receives an event;&lt;/li&gt;&#xA;&lt;li&gt;it updates the database successfully;&lt;/li&gt;&#xA;&lt;li&gt;the process crashes before acknowledging the message;&lt;/li&gt;&#xA;&lt;li&gt;the broker makes the message visible again;&lt;/li&gt;&#xA;&lt;li&gt;another consumer receives it.&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;The broker cannot know that the database update happened. Redelivery is the safer choice.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
