Concurrency vs Parallelism

These two words get used interchangeably in casual conversation, but they describe genuinely different things, and the distinction is a favorite precision-check in interviews: concurrency is about structuring a program to deal with multiple things at once; parallelism is about actually executing multiple things at the exact same instant. A system can be concurrent without being parallel, and the difference matters for how it actually behaves under load.

Concurrency: dealing with many things

A concurrent program is structured so that multiple tasks can be in progress at overlapping times, even if only one instruction is literally executing at any given nanosecond. A single CPU core running a web server handling many requests "concurrently" is really rapidly switching between them — starting one request, waiting on its database call, using that gap to make progress on another request, and so on — creating the appearance of simultaneous progress without ever truly running two things at once.

System Design Lab

Parallelism: doing many things at once, literally

Parallelism requires actual hardware capable of simultaneous execution — multiple CPU cores, multiple machines — with genuinely independent instructions running at the exact same moment. Splitting an array in half and summing each half on two different CPU cores at the same time is parallelism: there's no interleaving, no illusion, two things are truly happening simultaneously.

Why the distinction actually matters

The practical consequence: concurrency is a way of structuring code to make good use of waiting time, and doesn't require multiple cores at all; parallelism requires multiple cores (or machines) and is specifically about throughput — doing more total work in the same wall-clock time. A concurrent design is valuable even on a single core because most real workloads spend much of their time waiting (on disk I/O, on a network call, on another service's response) — exactly the case Message Queues exploit by letting a consumer pick up other work while waiting on a slow operation, rather than blocking idly. Parallelism, by contrast, is what actually turns more CPU cores or more machines into more completed work per second — the mechanism underneath Horizontal Scaling: splitting work across many machines only helps because those machines execute in parallel.

A concurrent design doesn't need to be parallel — and vice versa

It's worth internalizing both directions of this: a single-threaded event loop (the model behind Node.js, for instance) is highly concurrent — juggling thousands of in-flight requests — while running on exactly one core, no parallelism at all. Conversely, running the exact same, entirely independent batch job on 100 separate machines is fully parallel without necessarily being "concurrent" in the structural sense — there's no interleaving or shared-waiting-time cleverness involved, just the same work replicated and run simultaneously.

Why this matters in an interview

Being precise about which one a design actually needs is the signal worth showing: "we need concurrency to handle many slow, I/O-bound requests efficiently on one server" is a different, and often more accurate, claim than "we need parallelism," which is really about needing more raw compute throughput across multiple cores or machines. Conflating the two — or using "parallel" to describe an interleaved, single-core design — is a small but noticeable imprecision in an interview setting.