¿Cuándo recurrirías a hilos, a procesos o a asyncio?

Usa asyncio para E/S de mucho volumen donde quieres miles de esperas concurrentes en un solo hilo, hilos para trabajo de E/S en el que solo hay librerías bloqueantes disponibles, y procesos para trabajo con carga de CPU que necesita núcleos de verdad. Las preguntas que deciden son si el trabajo espera o calcula, y si las librerías de las que dependes ofrecen una interfaz asíncrona.

Mi primera pregunta siempre es si el trabajo espera o si calcula, porque esa respuesta elige la herramienta. Esperar en red o en disco significa asyncio si las librerías cliente lo soportan, porque un event loop mantiene tan tranquilo diez mil sockets abiertos en un núcleo y la memoria por tarea es mínima. Si el único driver disponible es bloqueante, uso un thread pool, porque un hilo aparcado en una lectura de socket libera el lock y no cuesta casi nada. Calcular significa procesos, o bajar a una librería nativa que suelte el lock por su cuenta. En un servicio en el que trabajé teníamos las dos cosas en la misma ruta de petición: un handler asíncrono repartiendo llamadas a seis APIs internas con gather, y una llamada a run_in_executor envolviendo un SDK bloqueante antiguo que no podíamos sustituir. Esa combinación vale la pena nombrarla en una entrevista porque la mayoría de los sistemas reales son mixtos. El error que vigilo es que alguien meta una transformación pesada de pandas dentro de una corrutina, porque entonces el loop deja de atender todo lo demás mientras se ejecuta.