Sync vs Async
A track of P32 · Concurrency & Parallelism.
The senior decision: CPU-bound versus I/O-bound, threads versus processes versus asyncio - a framework for choosing the right concurrency tool, and the bridge into P33's event loop.
"Should this be async?" is a question that has sunk more than one rewrite. The honest answer is almost always: it depends on one thing — is the work waiting, or is it computing? This short track gives you the decision framework a senior engineer uses, so the choice stops being a guess.
The first question is the only hard one: CPU-bound or I/O-bound? CPU-bound work keeps a core busy and needs processes to go parallel (the GIL blocks threads). I/O-bound work mostly waits, and there the GIL is out of the way — so a handful of concurrent calls suit threads, while thousands of them suit asyncio, which parks all that waiting on a single event loop with no per-thread cost. The catch with asyncio is that it is all-or-nothing: one blocking call freezes the entire loop, so the whole stack must be async.
And the framework's most valuable output is sometimes "none of the above" — if the work is small and fast, the overhead of pools and loops costs more than it saves. Measure first; add concurrency only when the profiler says the waiting or the CPU time is the real bottleneck. The track closes with a free-form interview rung that asks you to write the decision table out loud, and points straight into P33, where the event loop stops being an abstraction and becomes code.