<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Redis on Python Brasil — Aprenda Python em Português</title>
    <link>https://python.dev.br/tags/redis/</link>
    <description>Recent content in Redis on Python Brasil — Aprenda Python em Português</description>
    <generator>Hugo</generator>
    <language>pt-br</language>
    <lastBuildDate>Mon, 25 May 2026 11:59:31 +0000</lastBuildDate>
    <atom:link href="https://python.dev.br/tags/redis/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>FastAPI Background Tasks, Celery e Redis: quando usar cada um</title>
      <link>https://python.dev.br/blog/fastapi-background-tasks-celery-redis-2026/</link>
      <pubDate>Sat, 23 May 2026 00:00:00 +0000</pubDate>
      <guid>https://python.dev.br/blog/fastapi-background-tasks-celery-redis-2026/</guid>
      <description>&lt;p&gt;Toda API Python chega em um ponto em que uma operação não deveria acontecer dentro da requisição principal. Enviar email, gerar PDF, processar imagem, sincronizar CRM, chamar uma API instável ou importar uma planilha grande são tarefas úteis, mas ruins para a experiência do usuário quando deixam o endpoint lento ou sujeito a timeout.&lt;/p&gt;&#xA;&lt;p&gt;No ecossistema Python, três caminhos aparecem com frequência: &lt;strong&gt;BackgroundTasks do FastAPI&lt;/strong&gt;, &lt;strong&gt;Celery&lt;/strong&gt; e filas simples com &lt;strong&gt;Redis&lt;/strong&gt;. Eles resolvem problemas parecidos, mas não têm o mesmo custo operacional nem a mesma confiabilidade. Escolher errado pode gerar uma arquitetura pesada demais para um produto pequeno ou frágil demais para um sistema que já está em produção.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Python e Redis: Cache, Filas e Pub/Sub em 2026</title>
      <link>https://python.dev.br/blog/python-e-redis/</link>
      <pubDate>Wed, 28 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://python.dev.br/blog/python-e-redis/</guid>
      <description>&lt;p&gt;Redis é um dos bancos em memória mais usados no ecossistema Python. Ele aparece como &lt;strong&gt;cache&lt;/strong&gt;, broker para filas, armazenamento de sessões, base para rate limiting, pub/sub e coordenação leve entre serviços. A integração com Python é direta usando &lt;code&gt;redis-py&lt;/code&gt;, mas o ganho real vem de saber quando Redis resolve o problema e quando você precisa de uma fila mais completa como Celery, RQ ou Dramatiq.&lt;/p&gt;&#xA;&lt;p&gt;Este guia foca no uso prático: conectar, cachear, limitar requisições, enfileirar tarefas simples e publicar eventos. Se a sua dúvida principal é tirar trabalho pesado de uma API, leia também &lt;a href=&#34;https://python.dev.br/blog/fastapi-background-tasks-celery-redis-2026/&#34;&gt;FastAPI Background Tasks, Celery e Redis&lt;/a&gt; e o verbete de &lt;a href=&#34;https://python.dev.br/glossario/celery/&#34;&gt;Celery&lt;/a&gt;. Redis é uma peça importante dessa arquitetura, mas não deve virar “banco principal disfarçado” nem fila crítica sem estratégia de recuperação.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Celery em Python: Filas de Tarefas, Workers e Redis</title>
      <link>https://python.dev.br/glossario/celery/</link>
      <pubDate>Wed, 03 Dec 2025 00:00:00 +0000</pubDate>
      <guid>https://python.dev.br/glossario/celery/</guid>
      <description>&lt;h2 id=&#34;o-que-é-celery&#34;&gt;O que é Celery?&lt;/h2&gt;&#xA;&lt;p&gt;&lt;strong&gt;Celery&lt;/strong&gt; é uma fila de tarefas distribuída para Python. Ela permite executar operações demoradas em segundo plano, fora do fluxo principal da aplicação. Em vez de fazer o usuário esperar pelo envio de um email, processamento de uma imagem ou geração de um relatório, você envia a tarefa para o Celery, que a executa de forma assíncrona em um processo separado chamado &lt;strong&gt;worker&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;p&gt;O Celery usa um &lt;strong&gt;broker de mensagens&lt;/strong&gt;, como Redis ou RabbitMQ, para intermediar a comunicação entre a aplicação que envia tarefas e os workers que as executam. Opcionalmente, um &lt;strong&gt;backend de resultado&lt;/strong&gt; armazena o retorno e o estado de cada tarefa.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
