Quando você usaria threads, processos ou asyncio?

Use asyncio para I/O de alto volume, quando você quer milhares de esperas concorrentes numa thread só, threads para trabalho de I/O em que só existem bibliotecas bloqueantes, e processos para trabalho CPU bound que precisa de cores de verdade. As perguntas decisivas são se o trabalho espera ou calcula, e se as bibliotecas das quais você depende oferecem interface async.

Minha primeira pergunta é sempre se o trabalho espera ou se ele calcula, porque essa resposta escolhe a ferramenta. Esperar por rede ou disco significa asyncio, se as bibliotecas cliente derem suporte, já que um event loop segura tranquilamente dez mil sockets abertos num core e a memória por task é minúscula. Se o único driver disponível é bloqueante, eu uso um thread pool, porque uma thread parada num read de socket libera o lock e custa quase nada. Calcular significa processos, ou descer para uma biblioteca nativa que solta o lock sozinha. Num serviço em que trabalhei tínhamos os dois no mesmo caminho de request: um handler async abrindo leque para seis APIs internas com gather, e uma chamada run_in_executor embrulhando um SDK bloqueante antigo que não dava para substituir. Vale citar essa combinação numa entrevista porque a maioria dos sistemas reais é mista. O erro que eu fico de olho é alguém colocar uma transformação pesada de pandas dentro de uma corrotina, porque aí o loop para de atender todo o resto enquanto aquilo roda.