Wie würdest du mit einem blockierenden Library-Aufruf in einem async FastAPI-Endpunkt umgehen?

Hol ihn von der Event Loop runter. Wickle den blockierenden Aufruf in asyncio.to_thread oder nutz run_in_executor mit einem Thread-Pool, damit die Loop frei bleibt, um andere Requests zu bedienen. Ist die Arbeit CPU-lastig, schick sie stattdessen in einen Process-Pool oder an einen Background-Worker wie Celery. Bleibt sie inline, legt ein langsamer Aufruf jeden anderen Request auf diesem Worker lahm.

Der Grund, warum es zählt, ist, dass asyncio kooperativ und single-threaded ist, eine Coroutine also die Loop behält, bis sie auf etwas awaitet. Ein blockierender Treiberaufruf in einem async Handler friert jeden anderen laufenden Request auf diesem Worker ein, und bei geringem Traffic merkst du das nie. Der billigste Fix in FastAPI ist, den Endpunkt mit einfachem def statt async def zu definieren, dann führt das Framework ihn für dich in seinem Threadpool aus. Wenn ich es innerhalb einer async-Funktion brauche, wickelt asyncio.to_thread den Aufruf und awaitet das Ergebnis. Vorsichtig bin ich bei der Größe des Thread-Pools, denn der Default ist klein und eine langsame Abhängigkeit staut sich dahinter, also dimensioniere ich ihn gegen die erwartete Nebenläufigkeit und setze ein Timeout. Für alles CPU-Schwere helfen Threads unter dem Default-Build nicht, das geht also in einen Process-Pool oder raus an einen Celery-Worker. Wir haben so einen Fall mit einem alten SOAP-Client erwischt, der acht Sekunden brauchte, und die p99-Latenz eines ganzen Service ist diesem einen Aufruf gefolgt.