<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Microservices on Lorbic</title><link>http://localhost:1313/tags/microservices/</link><description>Recent content in Microservices on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 01 Feb 2026 13:00:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/microservices/index.xml" rel="self" type="application/rss+xml"/><item><title>Python Background Workers: Architecture, Queues, and Retry Strategies</title><link>http://localhost:1313/building-production-ready-background-workers-in-python/</link><pubDate>Sun, 01 Feb 2026 13:00:00 +0530</pubDate><guid>http://localhost:1313/building-production-ready-background-workers-in-python/</guid><description>&lt;p>I thought processing audio in the background was simple: spawn a thread, run the script, save the file. Then I hit 200 concurrent requests, and it failed epically.&lt;/p>
&lt;p>The CPU spiked to full usage because of pydub&amp;rsquo;s processing. The TTS API didn&amp;rsquo;t rate-limit me but, it was horribly slow. Then the jobs started failing. Half the jobs died silently. The other half wrote corrupted files because of race conditions I didn&amp;rsquo;t know existed. And when I deployed a little fix? The deployment killed in-flight jobs, leaving orphaned audio segments scattered across cloud storage directory.&lt;/p></description></item></channel></rss>