<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Race-Conditions on Kuldeep Pisda</title><link>https://kdpisda.in/tag/race-conditions/</link><description>Recent content in Race-Conditions on Kuldeep Pisda</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 07 Mar 2026 10:00:00 +0530</lastBuildDate><atom:link href="https://kdpisda.in/tag/race-conditions/index.xml" rel="self" type="application/rss+xml"/><item><title>Ambarsthan Bookings: Let the Database Win the Race</title><link>https://kdpisda.in/ambarsthan-concurrent-bookings-in-the-database/</link><pubDate>Sat, 07 Mar 2026 10:00:00 +0530</pubDate><guid>https://kdpisda.in/ambarsthan-concurrent-bookings-in-the-database/</guid><description>&lt;p&gt;In the last chapter I poured the walls between our Celery workloads so a slow transcode could never delay a donor&amp;rsquo;s payment — isolation by named queue, one worker per latency class. That was about &lt;em&gt;fairness&lt;/em&gt; under load: making sure nobody waits behind the wrong thing. This chapter is about the harder cousin of that problem — &lt;em&gt;correctness&lt;/em&gt; under load. Not &amp;ldquo;who goes first,&amp;rdquo; but &amp;ldquo;what happens when two people try to take the exact same thing at the exact same instant, and both of them are right to think it&amp;rsquo;s available.&amp;rdquo;&lt;/p&gt;</description></item></channel></rss>