Fazendo chamadas de API com aipo

Estou projetando um sistema para um cliente em que os requisitos são:

• eles carregam um arquivo JSON (um objeto / linha)
• faça uma chamada para uma API com o objeto JSON como a carga útil
• registre o estado (sucesso / falha) de cada chamada da API em um banco de dados
• faça uma nova tentativa se houver uma falha.

Eu decidi construí-lo usando aipo e um banco de dados sqlite como back-end. O número de linhas JSON não é grande - talvez um milhão no máximo - que cabe na memória. Eu tenho todos os componentes individuais funcionando bem (pode fazer upload de arquivos, ler arquivos, chamar API, gravar em db etc.), mas não tenho certeza da arquitetura geral das tarefas de despacho usando o aipo.

Supondo que haja N linhas no arquivo, devo:

Opção A:

1. Crie N objetos no banco de dados com uma resultcoluna (inicialmente nula).
2. Crie N tarefas de aipo e passe o ID do objeto como parâmetro e carga útil
3. Faça a subtarefa chamar a API e atualize o campo de resultado do objeto para êxito / falha.
4. Deixe o recurso de nova tentativa do aipo tentar chamar a API novamente em caso de falha.

Opção B:

1. Crie N objetos no banco de dados com uma resultcoluna (inicialmente nula).
2. Crie 1 tarefa de aipo e passe a lista inteira de N IDs de objetos e N cargas úteis
3. Passe por todos os N objetos e atualize o banco de dados com o resultado a cada etapa.
4. Quando a tarefa anterior termina, ela dispara outra tarefa única de aipo que lê o banco de dados para todos os objetos com resultado de falha e os tenta novamente.

Eu sou a favor da opção A por causa de sua simplicidade, mas não sei quais são os limites no número de tarefas de aipo que podem ser agendadas e se o broker (RabbitMQ) lidará com isso. Com a opção B, o grande risco é que, se a tarefa de aipo terminar por algum motivo em alguma linha M, todos os objetos a seguir nunca serão tentados.

Alguma opinião sobre esses dois ou se há uma terceira alternativa melhor?

A opção A soa como o caminho a percorrer, pois você pode definir os trabalhadores como a API independentemente, em vez de realizar grandes tarefas que apenas um único trabalhador pode gerenciar.

Eu tenho um cenário muito semelhante usando o kombu e o aipo:

• Recebemos uma mensagem postada no RMQ por alguma integração a uma fila RMQ
• Temos um consumidor de kombu que drena eventos
• Quando o evento é recebido, executamos o retorno de chamada (postar na fila python local)
• o aipo recebe a mensagem enviada pela fila python e processa-a
• Uma vez terminado, retorna os resultados e transmitimos a mensagem a um produtor de kombu
• O produtor publica de volta ao RMQ

Como você pode ver, usamos basicamente a mesma abordagem que você. Temos isso na produção, processando cerca de 2000 mensagens por hora, sem nenhum problema.