Server
CPU-bound
CPU-bound work is limited by how fast the processor can run instructions, not by waiting on disk, database or network. Adding faster or more cores helps. Adding faster storage does not.
How it is measured
The signal is a core pegged near 100 percent user time while I/O wait stays low. Check `top` or a profiler: if the process is on-CPU in your own code, hashing, compressing, rendering or parsing, the work is CPU-bound.
Confirm by looking at per-core use. A single-threaded runtime like Node can be CPU-bound at 100 percent of one core while the machine's overall figure reads 12 percent on eight cores.
Worked example
A Next.js site generates PDF invoices on request with a synchronous renderer. Each invoice takes 700 ms of pure CPU. On a 2-core box, 3 invoices a second pins both cores, and the product pages on the same server slow from 90 ms to 1.4 seconds.
Moving rendering to a queue with one dedicated worker keeps page latency flat. Invoices take a bit longer, but nobody waits for them.
How it differs
CPU-bound work waits on the processor. I/O-bound work waits on something outside it, like a disk or a socket. CPU-bound excludes time spent idle on a response. I/O-bound excludes heavy computation. The fix differs: CPU-bound work needs fewer cycles or more cores, I/O-bound work needs more concurrency.
Common errors
Adding RAM to fix a CPU problem. Reading average CPU across cores and missing a single saturated one. Running heavy synchronous code on the Node event loop. Scaling out when the cost is a per-request hot loop. Treating high load average as proof of CPU use when it counts blocked tasks too.
In practice
Profile one slow endpoint with a flame graph before changing hardware. Move image resizing, PDF generation and hashing off the request path, and cache their output. If the hot function is yours, fixing it beats buying cores.