Cola de tareas (Celery) que procesa operaciones de larga duración sin bloquear al usuario: notificaciones, emisión de comprobantes, generación de reportes y sincronización con terceros.
¿Qué es?
Celery es una cola de tareas distribuida. El backend encola los trabajos en Redis y unos workers (procesos Python independientes) los ejecutan en segundo plano, sin que el usuario tenga que esperar. La petición responde de inmediato mientras la operación pesada se procesa aparte.
Funciones principales
Notificaciones: Al confirmarse un pedido se encola el aviso al cliente; el worker lo ejecuta y la notificación llega en segundos.
Emisión de comprobantes: Una tarea invoca a SUNAT, genera el PDF y lo deposita en el almacenamiento; el usuario ve "generando…" y luego el enlace de descarga.
Sincronización de stock: Cada pocos minutos, una tarea concilia el inventario con sistemas externos.
Reportes programados: Una tarea genera el reporte de ventas diario y lo envía por correo a la gerencia.
Mantenimiento de datos: Depuración de carritos abandonados y sesiones caducadas, en horario nocturno.
Reintento de webhooks: Si la llamada al courier falla, se reintenta automáticamente con espera creciente (1, 5 y 15 minutos).
Limitaciones y restricciones
Consistencia eventual: La tarea no termina de inmediato; si el usuario recarga antes de completarse, puede ver un estado anterior.
Fallo silencioso: Si un worker cae durante una tarea, esta puede perderse sin aviso; exige monitorización.
Duplicación: Procesar dos veces la misma tarea podría emitir dos comprobantes; requiere idempotencia.
Escalado de workers: Ante muchos pedidos simultáneos, la cola crece y se necesitan más workers.
Diagnóstico complejo: Depurar un error en segundo plano es más difícil que en una petición síncrona.
Propósito del componente
Ejecutar operaciones largas sin bloquear al usuario, ofreciendo respuesta inmediata; escalar de forma independiente del API; y aislar la lógica, ya que un worker es un proceso separado que puede reiniciarse sin afectar al backend.
Por qué: Celery es el estándar en Django. Redis actúa como broker de baja latencia. Flower visualiza el estado de las tareas. APScheduler gestiona las tareas recurrentes (cron). Sentry notifica los errores en segundo plano.
Información técnica adicional
Reintentos: Ante un fallo, la tarea se reintenta automáticamente; se configuran max_retries y retry_backoff.
Tiempos límite: Una tarea no debe exceder cierta duración; si se bloquea, el worker termina el proceso.
Limitación de tasa: Acota cuántas tareas del mismo tipo se ejecutan a la vez para no saturar SUNAT.
Idempotencia: La tarea debe producir el mismo resultado si se ejecuta dos veces; es clave para la fiabilidad.
Seguimiento de estado: El usuario puede ver el progreso: "Procesando…" → "Completado" → "Con error".
Métricas importantes
Profundidad de cola: Tareas en espera de ejecución; por encima de 1000, añadir workers.
Tasa de éxito: Porcentaje de tareas completadas frente a fallidas; objetivo superior al 99%.
Tiempo de ejecución (P95): Notificación < 1 s, comprobante < 5 s, reporte < 30 s.
Disponibilidad de workers: Porcentaje de tiempo operativos; alertar por debajo del 95%.
Tasa de error: Porcentaje de tareas fallidas; por encima del 1% indica un defecto o una integración rota.
El procesamiento asíncrono mejora notablemente la experiencia de usuario, pero exige disciplina: toda tarea debe ser idempotente, con reintentos y monitorización. Sin ello, el riesgo es la corrupción de datos y la insatisfacción del cliente.