Como escolher entre threads, processos e asyncio para uma carga de trabalho em Python

Objetivo

Escolher o modelo de concorrência que corresponde ao gargalo da carga de trabalho, antes que o design se consolide em torno de um modelo errado.

Pré-requisitos

Um perfil ou uma medição que indique onde o tempo é gasto no caminho crítico: esperando por I/O (sockets, discos, subprocessos), executando bytecode Python (parsing, cálculo numérico em Python puro) ou executando código nativo que libera a GIL (compressão, hashing, muitas operações com arrays). Veja "Profile before optimising".

Passos

1. Conte as esperas concorrentes. Milhares de conexões, ou bibliotecas nativamente assíncronas, apontam para asyncio. Algumas dezenas de chamadas bloqueantes feitas por bibliotecas síncronas apontam para um ThreadPoolExecutor; a documentação afirma que o número padrão de workers é min(32, cpu_count + 4) (baseado em os.process_cpu_count() desde a versão 3.13), escolhido para manter pelo menos cinco workers para tarefas limitadas por I/O.
2. Se o gargalo é o bytecode Python, threads não ajudam no build padrão: o glossário define a GIL como o mecanismo que permite que apenas uma thread execute bytecode Python por vez. Use ProcessPoolExecutor (ou multiprocessing), ou um build free-threaded, se todas as dependências o suportarem.
3. Se o gargalo é código nativo que libera a GIL, as threads oferecem paralelismo sem o custo de serialização dos processos; confirme com uma execução com dois workers contra uma com um, usando dados reais.
4. Para processos, defina o método de início explicitamente com get_context(). A documentação afirma que, em POSIX, o padrão mudou de fork para forkserver no Python 3.14 e que o macOS usa spawn como padrão desde a 3.8; argumentos e resultados precisam ser serializáveis com pickle, então passe identificadores em vez de objetos grandes e abra as conexões dentro do initializer do worker.
5. Limite tudo: max_workers, um asyncio.Semaphore ou o tamanho de uma fila; um fan-out sem limite transfere a falha para o serviço downstream.
6. Combine os modelos de forma deliberada: asyncio.to_thread para uma chamada bloqueante dentro de um loop, loop.run_in_executor com um pool de processos para trabalho de CPU dentro de um servidor assíncrono.
7. Escreva o caminho de encerramento: executor.shutdown(cancel_futures=True), cancelamento de tarefas e um timeout em cada future.result().

Resultado esperado

Uma nota de decisão curta que nomeie o gargalo, o modelo, o limite e o método de início, junto com um pequeno benchmark que mostre o modelo escolhido superando a linha de base de thread única na carga de trabalho real.

Limites e base de verificação

As regras seguem a documentação citada, não medições. Cargas mistas podem exigir dois pools. Builds free-threaded alteram o passo 2; veja o artigo sobre a GIL e a pergunta em aberto sobre quando esses builds compensam.