<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>reliability on gabi cavalcante</title><link>https://gabicavalcante.dev/tags/reliability/</link><description>Recent content in reliability on gabi cavalcante</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 12 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://gabicavalcante.dev/tags/reliability/index.xml" rel="self" type="application/rss+xml"/><item><title>Reliability in Django and Celery: how tasks get lost</title><link>https://gabicavalcante.dev/posts/reliability-in-django-and-celery/</link><pubDate>Wed, 12 Aug 2026 00:00:00 +0000</pubDate><guid>https://gabicavalcante.dev/posts/reliability-in-django-and-celery/</guid><description>&lt;p&gt;Every Django project I have worked on reaches the same moment. A request is too slow, someone moves the slow part into a Celery task, and the page gets fast. Quietly, the function has stopped being a function. It became a message, handed to a broker you do not control, to be run by a worker that might die halfway through. This post is my study guide for everything that can go wrong in that handoff, and what to do about each case.&lt;/p&gt;</description></item></channel></rss>