Hacer llamadas API con apio

Estoy diseñando un sistema para un cliente donde los requisitos son:

• suben un archivo JSON (un objeto / línea)
• hacer una llamada a una API con el objeto JSON como carga útil
• registrar el estado (éxito / fracaso) de cada llamada API en una base de datos
• vuelva a intentarlo si hay una falla.

Decidí construirlo usando apio y una base de datos sqlite como back-end. El número de líneas JSON no es grande, quizás un par de millones como máximo, lo que cabe en la memoria. Tengo todos los componentes individuales funcionando bien (puede cargar archivos, leer archivos, llamar a API, escribir a db, etc.), pero no estoy seguro acerca de la arquitectura general de despacho de tareas usando apio.

Suponiendo que haya N líneas en el archivo, debería:

Opcion A:

1. Cree N objetos en la base de datos con una resultcolumna (inicialmente nula).
2. Cree tareas de N celery y pase la identificación del objeto como parámetro y la carga útil
3. Haga que la subtarea llame a la API y actualice el campo de resultados del objeto a éxito / error.
4. Deje que la función de reintento de apio intente llamar a la API nuevamente en caso de falla.

Opcion B:

1. Cree N objetos en la base de datos con una resultcolumna (inicialmente nula).
2. Cree 1 tarea de apio y pase la lista completa de N identificadores de objetos y N cargas útiles
3. Recorra todos los N objetos y actualice la base de datos con el resultado en cada paso.
4. Cuando finaliza la tarea anterior, dispara otra tarea de apio única que lee la base de datos de todos los objetos con resultado de falla y los vuelve a intentar.

Estoy a favor de la opción A debido a su simplicidad, pero no sé cuáles son los límites en la cantidad de tareas de apio que se pueden programar y si el corredor (RabbitMQ) lo manejará. Con la opción B, el gran riesgo es que si la tarea de apio se terminara por algún motivo en alguna línea M, los siguientes objetos nunca se intentarán.

¿Alguna idea sobre estos dos o si hay una tercera mejor alternativa?

La opción A parece el camino a seguir, ya que puede configurar a los trabajadores en la API de forma independiente en lugar de grandes tareas que solo un solo trabajador puede administrar.

Tengo un escenario muy similar usando kombu y apio:

• Recibimos un mensaje publicado en RMQ por alguna integración a una cola de RMQ
• Tenemos un evento de drenaje de consumo de kombu
• Cuando se recibe el evento, ejecutamos la devolución de llamada (publicar en la cola local de Python)
• el apio recibe el mensaje enviado a través de la cola de Python y lo procesa
• Una vez terminado, devuelve los resultados y transmitimos el mensaje a un productor de kombu
• El productor publica nuevamente en RMQ

Como puede ver, utilizamos básicamente el mismo enfoque que usted. Tenemos esto en producción manejando alrededor de 2000 mensajes por hora sin ningún problema.