Concurrency and coordination

your service is handling four hundred requests at once on eight cores, interleaving them whenever one is waiting on I/O.

Concurrency

you split the batch across eight cores so eight rows are genuinely being computed at the same instant.

Parallelism

the bug only shows up under load, never in tests, and the outcome depends on which of two threads got there first.

Race condition

you wrap the shared counter in a lock so only one thread can be inside that block at a time.

Mutex

you allow at most ten things through at once, not one, because the thing you are protecting is a capacity rather than a variable.

Semaphore

you added more workers and throughput did not improve, because they are all queued behind the same lock.

Lock contention

two transactions each hold a lock the other one needs and both sit there until the database kills one of them.

Deadlock

the low-priority job never runs because higher-priority work keeps arriving and taking the resource first.

Starvation

you take a lock on the row up front with SELECT FOR UPDATE, so everyone else waits until your transaction ends.

Pessimistic locking

you read the row with its version, write it back only if the version has not changed, and retry the whole thing if it has.

Optimistic locking

you update the value only if it still equals what you last read, and loop round to try again if somebody beat you to it.

Compare-and-swap

you need only one instance across the whole fleet to run the job, so they all try to claim a key in Redis first.

Distributed lock

you can safely run the same operation five times and the system ends up in exactly the state it would after one.

Idempotent

you run it twice with the same input and get byte-identical output, because nothing inside it reads the clock or a random number.

Deterministic

you keep a fixed set of threads and hand them tasks, instead of spawning a new thread for every request.

Thread pool

you reuse a fixed set of open database connections instead of paying the handshake on every query.

Connection pool

one thread sits in a loop pulling ready events off a queue and running the callback for each one.

Event loop

the thread issues the request and goes off to do other work instead of sitting there waiting for the socket.

Non-blocking I/O

one slow request at the front of the queue holds up every fast request stuck behind it.

Head-of-line blocking