Parallelism and Concurrency
The distinction between structuring work so it can make progress independently and actually executing work simultaneously on multiple cores.
Concurrency is a structuring property; parallelism is an execution property. A single-core machine can be highly concurrent and not parallel at all.
The distinction determines what improves performance. I/O-bound work benefits from concurrency: threads or tasks waiting on network and disk can be interleaved, and one core can service thousands of in-flight operations. CPU-bound work needs parallelism, and is bounded by core count.
Getting this wrong produces two familiar mistakes: adding threads to a CPU-bound service, which adds context switching and no throughput; and using a synchronous blocking model for an I/O-heavy service, which consumes a thread per in-flight request and exhausts the pool at a fraction of achievable load.
Asynchronous I/O decouples in-flight operations from threads, which is why event-loop and coroutine models handle far more concurrent connections per unit of memory.
The costs are real and worth naming: shared mutable state requires synchronisation, which introduces contention, deadlock and non-deterministic bugs — and contention often appears as low CPU with high latency, invisible to CPU profiling and diagnosable only with a lock or blocking profile.