Concurrency and Coordination

In a distributed system, many processes work at the same time, often on the same data. That creates three separate problems: controlling access, coordinating timing, and agreeing on what the data currently is.

Concurrency Control

Concurrency control manages simultaneous access to shared resources or data, so multiple processes can work efficiently without producing conflicts or inconsistencies.

Three techniques do it.

Locking. A lock restricts access to a shared resource or piece of data so that only one process can use it at a time. Simple, and it works by making everyone else wait.

Optimistic concurrency control. This assumes conflicts are rare. Processes are allowed to run simultaneously, and conflicts are detected and resolved afterwards, usually by validating the work and rolling back if it clashed. It is a bet: when conflicts really are rare, nobody waits for anybody.

Transactional memory. Multiple operations are grouped into a transaction that executes atomically, which keeps the data consistent and the operations isolated from each other.

Synchronization

Synchronization coordinates the execution of multiple processes or threads so the system behaves correctly.

Barriers hold processes at a point until they have all reached it, then let them all continue.

Semaphores are signalling mechanisms that control access to shared resources and keep processes in step.

Condition variables let a process wait until a specific condition is true before continuing.

The Difference Between Them

These two get treated as the same thing. They are not.

Concurrency control is about access. Its goal is managing who can reach a shared resource when several processes are running at once, and its concern is what happens when two of them want to change the same data.

Synchronization is about timing. Its goal is coordinating the order and timing of concurrent processes, making sure certain operations happen before others and that processes do not interfere with one another.

One answers "may you touch this?" The other answers "is it your turn yet?"

Coordination Services

Coordination services are specialized components that provide ready-made primitives for the hard parts of running a distributed system: configuration management, service discovery, leader election, and distributed locking.

Apache ZooKeeper, etcd and Consul are the usual examples.

The reason they exist is that every one of those primitives is difficult to get right, and getting them subtly wrong produces failures that only appear under load.

Consistency Models

A consistency model defines the rules for how and when a change made by one operation becomes visible to other operations. Each one trades differently between consistency, availability and partition tolerance.

Strong consistency. Once a write completes, any subsequent read immediately sees the new value. Traditional relational databases like MySQL and PostgreSQL typically offer this.

Eventual consistency. All reads of a data item will eventually return the last written value, with no guarantee of how long that takes. Amazon's DynamoDB works this way.

Causal consistency. Operations that are causally related are seen in the same order by everyone, while unrelated concurrent operations may be seen in different orders on different nodes. In a social app, if someone posts a message and then comments on it, any user who sees the comment must also see the original post.

Read-your-writes consistency. Once a write completes, subsequent reads by that same client see it. Updating your profile and immediately seeing the new version is this guarantee.

Session consistency. A stronger form of read-your-writes that extends the guarantee across a whole session of interactions. Items added to a shopping cart stay consistently visible for the rest of that visit.

Sequential consistency. Operations from all nodes are seen in the same order everywhere. There is a global order, but it does not have to match real time. A distributed logging system merging logs from many servers into one consistent log works this way.

Monotonic read consistency. Once a read has seen a value, later reads never see an older one. Checking a flight status, the departure time may move forward but will not jump backwards.

Linearizability. A stronger form of sequential consistency: every operation is atomic and instantly visible to all nodes, not merely globally ordered. In a distributed key-value store, once a key is written, a read on any node reflects it immediately.

Read that list as a ladder. Each step up adds a guarantee and takes something away in performance, availability, or both. The right rung depends on what the application actually needs.

💡 The strongest answer to "which consistency model?" names the operation, not the system. "Reads of the account balance need linearizability, but the activity feed can be eventually consistent" is a real design. Systems are rarely one model throughout.

Key takeaway: Concurrency control manages access to shared data using locks, optimistic control that assumes conflicts are rare and resolves them afterwards, or transactional memory. Synchronization coordinates timing using barriers, semaphores and condition variables. Coordination services like ZooKeeper, etcd and Consul supply configuration management, service discovery, leader election and distributed locking. Consistency models form a ladder from eventual up to linearizability, each rung adding a guarantee and costing performance or availability.

The next lesson, Monitoring and Observability, covers how you find out what a system this complicated is actually doing.