18/10/2026 –, Principal
Em sistemas Python, filas, workers e tasks em background ajudam a escalar, mas também podem tornar falhas mais difíceis de entender. A talk propõe discutir quando esse caminho faz sentido.
Em aplicações Python, é comum começar com uma API simples em Django, Flask ou FastAPI e, com o tempo, mover tarefas mais pesadas para background usando Celery, Redis, RabbitMQ ou até fluxos com asyncio. No papel, isso parece ótimo: a aplicação responde mais rápido, o processamento fica desacoplado e o sistema ganha mais fôlego para crescer.
Só que essa mudança também traz um novo tipo de complexidade. Uma task pode rodar duas vezes, uma mensagem pode chegar fora de ordem, um retry pode causar efeito colateral e um erro pode acontecer longe demais da requisição original. O que parecia apenas uma melhoria de performance pode virar um sistema mais difícil de entender, observar e manter.
Nesta talk, quero discutir esse momento tão comum no ecossistema Python: quando sair do fluxo síncrono realmente ajuda e quando isso só adiciona camadas demais ao sistema. A proposta é mostrar, com foco em aplicações Python, os trade-offs entre request/response tradicional, tarefas em background e comunicação orientada a eventos.
Também quero explorar práticas que fazem bastante diferença nesse cenário, como idempotência, logs e métricas, DLQ, desenho mais cuidadoso de tasks e eventos, e o uso consciente de ferramentas como Celery e asyncio. No fim, a ideia é simples: ajudar a audiência a tomar decisões mais maduras sobre concorrência e arquitetura assíncrona em Python, entendendo quando essas soluções resolvem um problema real — e quando só complicam.
É importante já ter contato com backend em Python, especialmente com APIs web, requisições HTTP e tarefas em background. Também ajuda conhecer, mesmo que de forma básica, frameworks como Django, Flask ou FastAPI e conceitos como filas, workers e mensageria.
Não é necessário dominar asyncio, Celery, Redis ou RabbitMQ, mas já ter visto esses termos antes facilita o acompanhamento da talk.
O que as pessoas que participarem podem esperar aprender na sua atividade?:Quem participar pode esperar aprender a identificar quando faz sentido tirar trabalho da requisição principal e usar filas, workers ou tasks em background em aplicações Python. A talk também mostra os problemas mais comuns desse tipo de solução, como duplicidade, retries, backlog e falhas difíceis de acompanhar.
A ideia é que o público saia com uma visão mais clara sobre como pensar esses trade-offs em sistemas Python, entendendo melhor quando o assíncrono ajuda de verdade, quais cuidados são importantes em produção e quando vale mais manter algo simples.
Escolha uma ou mais áreas em que essa proposta se encaixa: Desenvolvimento Web, Arquitetura de software
Engenheiro de Software com 6 anos de experiência em Python, backend, cloud, IA e machine learning, com foco em arquitetura, performance, automação e sistemas distribuídos.