<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Consistency on Nalar</title>
    <link>https://nalar.dev/tags/consistency/</link>
    <description>Recent content in Consistency on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 11 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/consistency/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Cache-Aside Consistency: Prevent Stale Overwrites</title>
      <link>https://nalar.dev/cache-aside-consistency-prevent-stale-overwrites/</link>
      <pubDate>Fri, 11 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/cache-aside-consistency-prevent-stale-overwrites/</guid>
      <description>&lt;h1 id=&#34;cache-aside-consistency-prevent-stale-overwrites&#34;&gt;Cache-Aside Consistency: Prevent Stale Overwrites&lt;/h1&gt;&#xA;&lt;p&gt;Cache-aside is attractive because the application controls a simple protocol. A read checks the cache first. On a miss, it reads the database and places the result in the cache. A write updates the database and then invalidates or refreshes the cache.&lt;/p&gt;&#xA;&lt;p&gt;Each step is easy to describe. Concurrency makes the combined behavior less obvious.&lt;/p&gt;&#xA;&lt;p&gt;A delayed cache fill can publish an older database value after a newer write has already completed. The database remains correct, yet later readers can receive stale data from the cache. This article develops the race precisely and presents practical designs that keep an old fill from replacing a newer state.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
