Concurrency vs Parallelism

One of the most common misconceptions in computer science is conflating concurrency with parallelism. As Go co-creator Rob Pike famously defined:

"Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once."

• Concurrency is a property of program structure: It is how you decompose a complex problem into discrete, independently executing units of computation (e.g., handling 100,000 active WebSocket connections where 99.9% are idle waiting for incoming packets). A concurrent program can run on a single-core processor via rapid time-slicing and interleaving.
• Parallelism is a property of program execution: It is the simultaneous physical execution of multiple calculations on separate physical CPU cores (or GPUs) at the exact same physical instant in time. Parallelism requires multiple physical execution units.

A well-structured concurrent program can run seamlessly on a 1-core embedded chip, and automatically achieve physical parallelism when deployed onto a 128-core cloud server without changing a single line of application code.

Consider a busy coffee shop handling dozens of customer orders:

• Concurrent Barista (1 Person on 1 Espresso Machine): The single barista grinds coffee beans for Customer 1, presses the brew button (I/O wait), and while water drips through the portafilter, turns around to take cash from Customer 2, and then steams milk for Customer 3. At any microsecond, only one human hand is moving, but the shop progresses 3 orders concurrently.
• Parallel Baristas (4 People on 4 Espresso Machines): Barista 1 pulls shots, Barista 2 steams milk, Barista 3 takes payments, and Barista 4 blends cold drinks simultaneously. Four independent physical workers execute tasks in parallel.

When scaling out distributed systems or multi-threaded applications, Amdahl's Law calculates the maximum theoretical speedup achievable by adding more CPU cores:

S_{latency}(s) = \frac{1}{(1 - p) + \frac{p}{s}}

Where:

• p = Proportion of the program that can be parallelized (e.g., 0.90 or 90%).
• (1 - p) = Strictly serial portion of the program (e.g., mutex lock acquisition, DB write-ahead logging, TCP handshake sequence).
• s = Number of parallel processing cores.

Crucial System Design Takeaway: Even if you deploy a 1,000-core supercomputer (s = 1000), if just 5% of your algorithm is strictly serial (1 - p = 0.05), the maximum speedup is hard-capped at:

Max Speedup = \frac{1}{0.05} = 20×

No amount of additional hardware or compute budget can exceed a 20x speedup unless the serial bottlenecks (locks, coordination, consensus rounds) are eliminated.

package main

import (
	"fmt"
	"runtime"
	"sync"
)

func main() {
	// Utilize all available CPU cores for physical parallelism
	numCPU := runtime.NumCPU()
	runtime.GOMAXPROCS(numCPU)

	jobs := make(chan int, 100)
	var wg sync.WaitGroup

	// Concurrency structure: Spawn worker pool across parallel cores
	for w := 1; w <= numCPU; w++ {
		wg.Add(1)
		go func(workerID int) {
			defer wg.Done()
			for job := range jobs {
				// Executes in parallel on distinct physical cores
				processJob(workerID, job)
			}
		}(w)
	}

	for j := 1; j <= 50; j++ { jobs <- j }
	close(jobs)
	wg.Wait()
}

func processJob(id int, j int) {
	fmt.Printf("Worker %d processing job %d\n", id, j)
}