Ha llegado el asesino de Celery de Django.

Durante casi 20 años, los desarrolladores de Django han lidiado con una omisión evidente: no hay una manera nativa de ejecutar tareas en segundo plano. Enviar correos electrónicos, procesar cargas, generar informes o llamar a APIs de terceros dependían de herramientas externas, siendo Celery el estándar de facto desde finales de los años 2000.

Ese estándar no oficial tuvo un costo. Los equipos tenían que añadir un bróker separado, un grupo de trabajadores y un sistema de monitoreo solo para evitar bloquear una única solicitud HTTP, incluso para trabajos triviales como "enviar un correo electrónico de bienvenida" o "recalcular un contador".

La comunidad ha expresado su queja sobre esta brecha durante más de una década en tickets, publicaciones en blogs y charlas en conferencias. Lo que la gente realmente quería sonaba simple: una API estandarizada y incorporada para el trabajo asíncrono que no obligara a usar Redis, RabbitMQ o una implementación específica de trabajadores en cada proyecto.

En cambio, el ecosistema se fragmentó. Algunos equipos apostaron todo por Celery; otros optaron por Huey, RQ o colas personalizadas. Cambiar uno significaba reescrituras invasivas, porque cada biblioteca incluía sus propios decoradores, objetos de resultado y semánticas de reintento integradas directamente en el código de la aplicación.

Esa presión finalmente se cristalizó en una propuesta formal de mejora de Django (DEP) del contribuyente principal Jake Howard. Su DEP de Django Tasks propuso un Marco de Tareas de Django mínimo y extensible que residiría en el núcleo, definiría la API pública y permitiría a los backends competir en detalles de implementación.

El diseño de Howard trazó una línea clara: Django sería responsable de cómo declaras y encolas tareas, mientras que los backends de terceros se encargarían del almacenamiento, los trabajadores y la escalabilidad. Esa división refleja cómo Django trata las bases de datos o las cachés, y resonó de inmediato con los mantenedores cansados de acoplar la lógica de negocio a una única biblioteca de colas.

Django 6.0, lanzado en diciembre de 2025 después de una alfa en septiembre, beta en octubre y RC1 en noviembre, es donde esa propuesta se materializa de verdad. El nuevo módulo de tareas se incluye como parte del marco, no como un complemento, y cada nuevo proyecto ahora cuenta con una gestión de trabajos en segundo plano de primera clase desde el primer día.

Arquitectónicamente, esto marca un punto de inflexión en la escala de las vistas asíncronas de Django o el framework de migraciones. El trabajo en segundo plano ya no es “algun sistema externo que se añade después”, sino una capacidad central sobre la que pueden basarse directamente otras funciones, aplicaciones de terceros y futuras DEP.

El nuevo Marco de Tareas de Django 6.0 traza una línea clara entre la definición y la ejecución. El núcleo de Django ahora estandariza cómo declarar una tarea y enviarla a una cola, pero se niega a dictar qué ejecuta esa cola, cómo son los trabajadores o dónde se almacenan los trabajos. Esa separación convierte las tareas en una capa de API intercambiable en lugar de un trabajador en segundo plano monolítico integrado en el ORM o la pila de solicitudes.

En el corazón del sistema se encuentra el decorador @task. Lo aplicas a una función normal, y Django lo registra como una tarea con metadatos como el nombre de la cola, la prioridad y si necesita un contexto de tarea. Las tareas deben existir en el ámbito del módulo, aceptar argumentos serializables en JSON y devolver valores, y pueden optar por `takes_context=True` para recibir un objeto de contexto que exponga el conteo de intentos y el ID de `TaskResult`.

Una vez que una función se convierte en una tarea, entregas trabajo al marco con `enqueue()`. Desde código sincrónico, llamas a `enqueue(my_task, *args, **kwargs)`; desde código asincrónico, los backends pueden exponer `aenqueue()` para la misma API, solo que con `await`. En el fondo, Django pasa esta llamada al backend configurado, que decide si eso significa enviar un mensaje a Redis, escribir en Postgres o hacer algo completamente personalizado.

Cada llamada a `enqueue()` devuelve un objeto TaskResult, que es la única abstracción de Django sobre "lo que sucedió con mi trabajo". Ese objeto lleva un ID único que puedes almacenar en tu base de datos o enviar de vuelta al cliente, y luego cargar más tarde a través de algo como `get_result(id)` para inspeccionar campos como estado, detalles de errores, intentos y valor de retorno. Los consumidores del marco nunca tocan directamente los internos del backend; interactúan con TaskResult y permiten que el backend lo mapee a su propio almacenamiento.

La incompletitud deliberada define este diseño. Django no incluye un trabajador de producción, un motor de reintentos, un programador al estilo cron ni una API de encadenamiento; todo eso pertenece a los backends o bibliotecas de terceros. El núcleo solo promete que `@task`, `enqueue()` y `TaskResult` se mantendrán estables para que el ecosistema pueda construir trabajadores, paneles y puentes hacia Celery, RQ o Redis.

Los backends iniciales se mantienen mínimos a propósito. El backend `immediate` ejecuta tareas de manera sincrónica tan pronto como llamas a `enqueue()`, lo que hace que las pruebas unitarias y la depuración local sean triviales porque los rastros de pila y los puntos de interrupción se comportan exactamente como las llamadas de funciones normales. El backend `dummy` descarta cada tarea sin ejecutar nada, ideal para entornos donde debes mantener las llamadas a las tareas en su lugar, pero no puedes permitir la ejecución real, como en ciertos ambientes de preproducción o de simulación.

El trabajo en segundo plano en Django significa sobre todo las mismas tres tareas, una y otra vez: enviar correos electrónicos, procesar cargas de usuario y comunicarse con API externas. Ese “caso de uso del 80%” raramente necesita flujos de trabajo distribuidos, enrutamiento distribuido o limitación de tasa por cola. Solo necesita dejar de bloquear el hilo de solicitud mientras un servidor SMTP, un bucket de S3 o un proveedor de pagos se activa.

El marco de tareas de Django se dirige a ese público directamente. Decoras una función con @task, llamas a `enqueue()` (o `aenqueue()`), y delegas trabajos como “envía este correo de restablecimiento de contraseña” o “genera miniaturas para esta imagen”. Para muchas aplicaciones, ese único patrón cubre restablecimientos de contraseña, secuencias de incorporación, envío de webhooks, generación de PDFs y calentadores de caché.

Históricamente, los equipos utilizaban Celery para esos trabajos y terminaban ejecutando una pila completa de colas para un puñado de funciones. Tenías un intermediario, un backend de resultados, un grupo de trabajadores, programación de beat y un sinfín de configuraciones antes de que tu primer correo electrónico saliera del edificio. Django Tasks Framework elimina ese requisito para casos simples al estandarizar la API mientras se mantiene agnóstico sobre la maquinaria pesada detrás de ella.

Piénsalo como una rampa de acceso: te comprometes a una forma de declarar y encolar tareas, mucho antes de comprometerte con RabbitMQ, Redis o una granja de trabajadores a escala de Kubernetes. Los proyectos en etapas tempranas pueden comenzar con el backend inmediato, y luego intercambiar por un trabajador respaldado por una cola real cuando el tráfico y la latencia lo exijan. Sin refactorización masiva, sin necesidad de eliminar decoradores específicos de Celery en toda la base de código.

Los propios backends de Django se mantienen intencionalmente minimalistas: un backend inmediato que ejecuta el trabajo en línea y un backend ficticio que nunca se ejecuta. Esto mantiene bajas las dependencias, hace que todo se sienta nativo de Django y evita integrar demonios adicionales para aplicaciones CRUD o herramientas internas. Para obtener detalles sobre backends, contexto y manejo de resultados, la Documentación del Marco de Tareas de Django 6.0 describe el contrato en el que se integran los trabajadores de terceros.

El trabajo en segundo plano en Django 6.0 comienza con una función de Python simple envuelta en el nuevo decorador @task. Un ejemplo mínimo se ve así:

```python from django.tareas import tarea, encolar, aencolar, obtener_resultado ```

@task( prioridad=5, nombre_cola="notificaciones", toma_contexto=True, ) def notificar_usuario(contexto_tarea, id_usuario, mensaje): """ Enviar una notificación a un usuario.

# Acceder a los metadatos sobre este intento de ejecución específico = task_context.intento # 1 en el primer intento, se incrementa en reintentos result_id = task_context.task_result_id # ID estable para seguimiento

# Tu lógica real va aquí (correo electrónico, push, SMS, etc.) # Puedes registrar el intento/result_id para visibilidad return {"estado": "enviado", "intento": intento, "result_id": result_id}

Esos argumentos de decorador son las principales configuraciones que Django expone. priority es una pista numérica para el backend; los números más altos significan “ejecutar antes” en relación con otros trabajos en la misma cola. queue_name dirige el trabajo a una cola específica como `"notificaciones"` o `"procesamiento-de-imágenes"`, mientras que `takes_context=True` inyecta un objeto task_context como el primer parámetro.

`task_context` convierte una función de "disparar y olvidar" en algo que realmente puedes observar. `task_context.attempt` expone cuántas veces se ha ejecutado esta tarea hasta ahora, lo cual se vuelve crítico una vez que tu backend añade reintentos. `task_context.task_result_id` te proporciona un identificador estable que puedes guardar en tu base de datos, registros o análisis para que puedas reconectar con esta ejecución más adelante.

El encolado de trabajo utiliza el helper enqueue() para código síncrono. Desde una vista o un controlador de señales, podrías hacer:

```python def crear_pedido(solicitud): # ... crear pedido, confirmar transacción ... resultado = encolar( notificar_usuario, usuario_id=solicitud.usuario.id, mensaje="¡Tu pedido está en camino!", ) # resultado.id == id_resultado_tarea return JsonResponse({"id_tarea": resultado.id}) ```

El código asíncrono utiliza `aenqueue()` en su lugar, reflejando las vistas y consumidores asíncronos de Django:

```python async def vista_asincrona(request): resultado = await aenqueue(notificar_usuario, user_id=1, mensaje="Hola") return JsonResponse({"id_tarea": resultado.id}) ```

Una vez que tengas un `task_result_id`, las verificaciones de estado se realizan a través de `get_result()`:

```python from django.http import JsonResponse from django.views.decorators.http import require_GET ```

@require_GET def estado_tarea(request, id_tarea): resultado = obtener_resultado(id_tarea) return JsonResponse( { "id": resultado.id, "estado": resultado.estado, # por ejemplo, "pendiente", "ejecutándose", "finalizada", "fallida" "intentos": resultado.intentos, # total de intentos hasta ahora "valor": resultado.valor, # valor de retorno de notificar_usuario, si ha finalizado "error": resultado.error, # información de error específica del backend, si ha fallado } )

Ese trío — `@task`, `enqueue()`/`aenqueue()`, y `get_result()` — forma la superficie mínima y estandarizada que debe respetar cada backend del Marco de Tareas de Django.

No hay sorpresas aquí: Django 6.0 no incluye un trabajador incorporado. Puedes definir y encolar tareas con el Marco de Tareas de Django, pero las configuraciones de producción aún necesitan un proceso separado de larga duración para extraer trabajos de un backend y ejecutarlos. La documentación oficial y las charlas iniciales enfatizan esto: un "trabajador de tareas de Django" o equivalente es obligatorio una vez que sales de la consola de desarrollo.

La API principal de Django también omite las comodidades que los usuarios de Celery dan por sentadas. No hay soporte oficial para reintentos automáticos cuando un proveedor de correo electrónico se agota, no hay horarios de estilo cron incorporados, y no hay cadenas o grupos de tareas nativos. Si quieres "ejecutar esto cada 5 minutos" o "comenzar la tarea C solo después de que A y B tengan éxito," no encontrarás esa lógica en django.tasks.

Esas características viven completamente en cualquier backend que implementes. Un trabajador respaldado por Redis, un puente RQ o un futuro adaptador de Celery pueden decidir cómo implementar reintentos, estrategias de retroceso, trabajos periódicos y canalizaciones de fan-out/fan-in. Django solo promete una superficie estable: `@task`, llamadas de encolado y una abstracción de TaskResult que los backends pueden extender.

Los diseñadores del Marco de Tareas de Django hicieron esta restricción explícita desde el primer día. Django Core incluye solo un backend inmediato (ejecuta tareas en línea) y un backend ficticio (nunca las ejecuta), ambos intencionalmente no destinados a producción. Cualquier cosa que realmente persista trabajos, coordine trabajadores o gestione la ejecución distribuida proviene de paquetes de terceros.

Esa división crea una línea clara de responsabilidad. Django es dueño de la interfaz: cómo declaras tareas, cómo pasas argumentos, cómo inspeccionas resultados. La comunidad es dueña de la implementación: cómo se serializan las tareas, dónde se encolan, cómo se escalan los trabajadores a través de contenedores o regiones.

Para los equipos acostumbrados a Celery, esto se siente casi como metal en bruto. Obtienes un punto de entrada estandarizado y respaldado por el marco, pero pierdes el programador, inspector y orquestación de reintentos que vienen incluidos hasta que tu backend elegido los reintroduzca. Los primeros experimentos ya tienen como objetivo Redis, RQ e incluso Celery como backends que utilizan la API del Marco de Tareas de Django.

A largo plazo, esto refleja el patrón existente de Django: las capas de ORM, caché y correo electrónico definen contratos, mientras que Postgres, Redis y los servidores SMTP hacen el trabajo pesado. Las tareas ahora se suman a esa lista, intencionadamente, de manera incompleta.

Celery construyó su reino sobre una promesa: trabajos en segundo plano de calidad industrial para Django mucho antes de que a Django le importara. Ahora, Django 6.0 presenta un Marco de Tareas de Django que integra las declaraciones de tareas en el núcleo, y de repente Celery ya no es la suposición predeterminada, solo el jugador más grande en el tablero.

Lado a lado, los modelos se ven muy diferentes. Django Tasks define una API estándar: `@task`, funciones de encolado y objetos `TaskResult`, mientras delega el almacenamiento y la ejecución a backends intercambiables. Celery ofrece una pila completa: broker, trabajadores, programadores, almacenamiento de resultados y una década de herramientas del ecosistema.

Una comparación rápida hace que la división sea obvia:

• 1Tareas de Django: parte de Django, configuración mínima, cargas útiles solo en JSON, backends requeridos para colas reales.
• 2Celery: paquete separado, requiere un intermediario como Redis o RabbitMQ, soporta serialización compleja, incluye trabajadores y programador de beat.
• 3Tareas de Django: ideales para correos electrónicos, cargas, llamadas a API y ganchos al confirmar.
• 4Celery: ajustado para clústeres distribuidos, alta capacidad de procesamiento y arquitecturas de múltiples servicios.

Celery sigue dominando donde la escala y la complejidad son importantes. Obtienes reintentos integrados con retroceso exponencial, tareas periódicas a través de beat y elementos fundamentales de flujo de trabajo como cadenas, grupos y acordes que orquestan docenas de trabajos entre muchos trabajadores. Las grandes implementaciones regularmente gestionan miles de tareas por segundo a través de Celery respaldado por Redis o RabbitMQ.

Django Tasks se enfoca fuertemente en la ergonomía. Te quedas dentro de Django, importas desde `django.tasks`, decoras una función y llamas a `enqueue()` sin tocar directamente un broker. Para aproximadamente el “80% de los casos de uso” — correos electrónicos transaccionales, generación de miniaturas, calentadores de caché, difusión de webhooks — esa sensación de cero dependencias dentro de Django elimina una barrera importante para la adopción.

Los usuarios avanzados perderán algunas ventajas si dejan de usar Celery hoy. No hay un trabajador oficial, ni políticas de reintento nativas, ni programación incorporada, ni una interfaz de usuario de monitoreo probada en batalla que venga con Django 6.0. Esos elementos se encuentran en backends comunitarios y paneles de terceros, que aún están rezagados respecto al ecosistema maduro de Celery.

Estrategicamente, Django Tasks cambia la pregunta predeterminada que hacen los equipos. Los nuevos proyectos comenzarán con el framework central y solo recurrirán a Celery cuando los requisitos exijan claramente flujos de trabajo distribuidos, enrutamiento avanzado o SLA estrictos. Celery se convierte en una vía de escalada, no en el punto de partida.

¿Entonces, Django 6.0 acaba con Celery? No, simplemente reduce el territorio de Celery. Los trabajos en segundo plano ahora pertenecen a Django por defecto, mientras que Celery defiende la frontera de alto rendimiento, multi-nodo y "nunca perder un trabajo". Para detalles técnicos más profundos, las Notas de la versión de Django 6.0 explican exactamente cómo el nuevo Marco de Tareas de Django se conecta a verdaderos backends.

Celery sigue ganando cada vez que tu trabajo en segundo plano deja de parecer una misión secundaria y comienza a parecer un sistema distribuido por derecho propio. Cuando necesitas cientos de trabajadores, múltiples colas distribuidas en varias regiones y un comportamiento predecible durante picos de más de 10,000 trabajos por segundo, las cicatrices de batalla de más de una década de Celery importan más que el nuevo brillo de Django.

Utiliza Celery cuando necesites lógica de enrutamiento avanzada en lugar de "disparar y olvidar". Eso significa características como: - Múltiples colas por servicio con claves de enrutamiento detalladas - Limitación de tasa y límites de concurrencia por tarea - Límites de tiempo duros y suaves, y comportamiento automático de cortacircuito

Los flujos de trabajo serios aún dependen del soporte de AMQP de Celery y de la flexibilidad de los corredores. Si tu arquitectura ya se basa en RabbitMQ, Redis o incluso en corredores más exóticos, obtienes colas duraderas, acuses de recibo de mensajes, intercambios de cartas muertas y semánticas de retroalimentación que el Marco de Tareas de Django intencionalmente no define.

Los pipelines complejos también te llevan de vuelta a Celery. Los acordes, grupos, cadenas y lienzos te permiten orquestar trabajos de distribución/recolección, pipelines ETL de múltiples pasos y cargas de trabajo de ciencia de datos de larga duración que pueden abarcar docenas de tareas y máquinas. La API de tareas de Django puede poner trabajos en cola, pero no modela ese tipo de gráfico de flujo de trabajo.

La monitorización es otra línea divisoria. Los equipos que trabajan dentro de Flower, los tableros de Prometheus y las tableros personalizados de Grafana basados en el flujo de eventos de Celery no aceptarán “ver el TaskResult” como una alternativa. Celery expone métricas por trabajador, profundidades de cola, tormentas de reintentos y histogramas de latencia de tareas que los SRE utilizan para mantener los SLA intactos.

Las plataformas SaaS de alto volumen, los backends fintech y los marketplaces que procesan millones de trabajos por día aún tratan a Celery como infraestructura fundamental. Para ese nivel, la probada semántica de reintento de Celery, los backends de resultados y las herramientas operativas siguen siendo inigualables por la joven capa modular de Django.

Las ondas de choque alcanzaron la tierra de Django casi tan pronto como se unió el Django Tasks Framework. A los pocos días de los candidatos para el lanzamiento de la versión 6.0, comenzaron a surgir repositorios de la comunidad con backends "experimentales" de Redis, ejecutores de tareas e integraciones administrativas que intentaban convertir la API básica en algo que se pueda llevar realmente a producción.

Los primeros adoptantes apuntaron al evidente vacío: un trabajador listo para producción que habla la nueva interfaz. Surgieron paquetes que envuelven listas o flujos de Redis, inician un comando de gestión de `worker` y mapean `priority` y `queue_name` desde `@task` directamente en las estructuras de datos de Redis, recreando efectivamente un corredor ligero al estilo de RQ detrás del Framework de Tareas de Django.

Redis se convirtió rápidamente en el parque de atracciones por defecto. Una familia de adaptadores se centra en configuraciones extremadamente simples: una sola instancia de Redis, colas FIFO, sin sharding, optimizadas para ese "caso de uso del 80%" de correos electrónicos, procesamiento de imágenes y llamadas a webhooks. Otra ola experimenta con características más avanzadas como trabajos retrasados, reintentos basados en retroceso y límites de tasa por cola, todo expuesto a través de simples kwargs de decorador.

Los paquetes de puente ahora tienen como objetivo conectar ecosistemas existentes en lugar de reemplazarlos. Ya puedes encontrar prototipos que te permiten reutilizar URL de brokers al estilo de Celery mientras enrutas todas las definiciones de tareas a través de `@task`, de modo que tu código se vea nativo pero tu infraestructura siga apoyándose en los trabajadores robustos y herramientas de monitoreo de Celery.

Los bocetos más ambiciosos son un "backend de Celery" que permitiría a Celery funcionar como un trabajador integrado detrás de la API estándar de Tareas de Django. La idea: las tareas permanecen nativas del marco, pero un adaptador de backend traduce las llamadas a `enqueue()` en tareas de Celery, mapea los IDs de resultados y actúa como intermediario en las verificaciones de estado, para que puedas migrar de manera incremental en lugar de reescribir años de código de tareas.

Las discusiones en la lista de correos de Django, los problemas de GitHub y los hilos de Twitter giran en torno a tres pilares que faltan: observabilidad, ganchos de ciclo de vida y una experiencia de usuario pulida en el administrador. La gente quiere eventos estructurados para "tarea iniciada / reintentada / fallida", backends de monitoreo intercambiables que puedan transmitir esos eventos a herramientas como Better Stack, y paneles de control de primera clase que muestren colas, trabajadores y rutas críticas directamente dentro del administrador de Django.

Si el patrón se mantiene, espera un ecosistema darwiniano en los próximos 6 a 12 meses: media docena de trabajadores de Redis, al menos un puente de Celery y algunas distribuciones "con baterías incluidas" con opiniones bien definidas compitiendo para convertirse en el estándar de facto para las tareas de Django 6.0.

JSON es lo primero. Las tareas de Django serializan los argumentos y los valores de retorno utilizando JSON, lo que significa que cualquier cosa que pases a una tarea debe ser compatible con JSON: cadenas, números, booleanos, listas, diccionarios. Si le entregas un `datetime`, un `Decimal` o una instancia de modelo, obtendrás errores de serialización o pérdida silenciosa una vez que los backends comiencen a imponer tipos estrictos.

Puedes sortear esto, pero tienes que ser explícito. Convierte objetos complejos en representaciones primitivas (IDs, cadenas ISO 8601, diccionarios simples) y réstauralos dentro de la tarea. Una buena regla: si no puede sobrevivir a un ciclo de `json.dumps()` / `json.loads()`, no lo envíes como argumento de tarea ni como valor de retorno.

Las escrituras en la base de datos introducen otro filo afilado. Si encolas una tarea durante una vista que se ejecuta dentro de `transaction.atomic()`, la tarea podría ejecutarse antes de que la transacción se confirme, ver datos obsoletos o fallar por filas faltantes. El gancho on_commit de Django existe precisamente para evitar esa carrera.

Patrón a recordar: haz la escritura, luego programa la tarea desde `on_commit`. Por ejemplo, después de crear un `Pedido`, usa `transaction.on_commit(lambda: send_order_email.enqueue(order_id=order.id))` para que el trabajador solo vea el estado confirmado. Omitir esto creará heisenbugs que solo aparecen bajo carga o con bases de datos lentas.

Los trabajadores aún viven fuera de tu proceso principal. Debes ejecutar un proceso de trabajador dedicado (o varios) bajo algo como systemd, Supervisor o Kubernetes Jobs. Eso significa manifiestos de despliegue adicionales, verificaciones de salud, logging y políticas de reinicio, tal como ya lo haces con Celery.

Operativamente, esta nueva pila reduce las dependencias pero no las responsabilidades. Aún necesitas considerar los límites de concurrencia, la presión en la cola y los apagados ordenados para que las tareas puedan finalizar antes de que los procesos terminen. Para muchos equipos, esa es una nueva capa operativa, no una característica gratuita.

Monitoreo de tierras en la categoría de "se requiere algún ensamblaje". Celery tiene Flower, exportadores de Prometheus y años de paneles de control; Django Tasks no cuenta con ninguno de esos elementos. Los backends iniciales exponen un estado básico a través de `TaskResult`, pero es probable que primero conectes vistas personalizadas de administración, registros o integración de APM.

La exploración a nivel de código fuente ayudará. El código fuente del marco de tareas de Django muestra exactamente cómo fluyen los resultados, estados y errores, en los que te apoyarás mientras esperas que las interfaces y métricas de terceros más completas se pongan al día.

Los proyectos de Django existentes deben considerar Django Tasks Framework como una actualización incremental, no como una migración de un día. Si ya utilizas Celery, RQ o Huey en producción y funcionan, mantenlos para los caminos críticos e introduce Django Tasks solo para nuevos flujos de bajo riesgo. Reescribir por completo configuraciones complejas de Celery rara vez compensa en la versión 1 de una nueva API.

Los nuevos proyectos que comienzan con Django 6.0 pueden hacer uso seguro de Django Tasks para las tareas del "80%": correos electrónicos, generación de miniaturas, calentadores de caché y llamadas sencillas a API de terceros. Recurre a Celery solo cuando sepas que necesitas flujos de trabajo entre servicios, trabajos programados a gran escala o miles de tareas por segundo en múltiples colas.

Los equipos que están atrapados en Django 5 aún pueden experimentar hoy usando el backport oficial. Instala el paquete de backport, conéctalo en `INSTALLED_APPS` y configura el backend inmediato o dummy para evitar tener que instalar Redis o RabbitMQ el primer día. Obtendrás el mismo decorador `@task` y la API `enqueue()` que en Django 6.0 sin necesidad de una actualización en todo el marco.

La experimentación segura significa seleccionar una característica no crítica y cambiarla a Django Tasks detrás de una bandera de característica. Los candidatos ideales incluyen:

• 1Correos electrónicos de restablecimiento de contraseña o confirmación de registro.
• 2“Gracias por registrarte” o “hemos recibido tu pedido” notificaciones
• 3Webhooks de bajo volumen para servicios de análisis o registro

Comienza moviendo un solo correo electrónico de restablecimiento de contraseña a una tarea en segundo plano que utilice `on_commit()` para encolar después de que se guarde el modelo de usuario. Utiliza el backend inmediato en desarrollo, luego cambia a un backend simple de Redis y a un solo proceso de trabajador en staging. Mide la latencia de solicitudes y las tasas de fallos de tareas antes de tocar cualquier cosa relacionada con los ingresos.

Trata la serialización solo en JSON como una función de forzado en lugar de una limitación: refactoriza los argumentos de la tarea a IDs y elementos primitivos en lugar de pasar instancias completas del modelo. Esa disciplina facilita cambiar entre Celery, un backend de Redis o cualquier futuro adaptador del Marco de Tareas de Django.

Estrategicamente, Django Tasks marca un punto de madurez para Django como un marco web que incluye todo lo necesario. El trabajo en segundo plano ahora habla una API común y central, lo que reduce la sobrecarga de dependencias y hace que Django sea más competitivo y auto­suficiente para la mayoría de las aplicaciones web que no requieren una orquestación de Celery de grado industrial.

¿Qué es el nuevo Marco de Tareas de Django?

Es una API integrada en Django 6.0 para definir y encolar tareas en segundo plano. Estandariza la forma en que se crean las tareas, pero requiere un sistema backend y un proceso de trabajador separados para su ejecución.

¿Django 6.0 reemplaza completamente a Celery?

No. El marco está diseñado para casos de uso más simples y comunes (la 'solución del 80%') como el envío de correos electrónicos. Para flujos de trabajo complejos y distribuidos con reintentos incorporados y cadenas, Celery sigue siendo la herramienta más poderosa.

¿Incluye el marco de tareas de Django un trabajador?

No, no lo hace. Esto es intencionado para mantener el núcleo de Django ligero. Debes configurar un backend de terceros y ejecutar un proceso de trabajo separado para ejecutar las tareas.

¿Puedo usar la nueva API de tareas con versiones anteriores de Django?

Sí, una biblioteca de retrocompatibilidad te permite utilizar la nueva API de tareas con Django 5, facilitando la experimentación y la preparación para la migración a Django 6.0.