Centralized, Decentralized And Distributed

Three Words That Get Mixed Up

People say centralized, decentralized and distributed as if they mean the same thing. They describe different things, and learning to separate them is the first skill of this course.

A system is a set of computers and programs that work together to do a job, such as delivering a message or storing a photo. Every system has two questions attached to it. The first is where the computers are and how they connect. The second is who decides what the system does. The three words answer these questions in different ways.

In 1964 the engineer Paul Baran, working at the RAND Corporation, drew three pictures of communication networks. The first looked like a star with one hub. The second looked like several stars linked together. The third looked like a fishing net with no special center. His drawings are still the simplest way to see the three ideas. We will use them throughout the course.

Centralized Systems

In a centralized system, one place holds the data and makes the decisions. Every user connects to that place. Think of a school office with one registrar. Every student asks the registrar for records, and the registrar's list is the truth.

Most of the web you use daily works this way. When you open a social app, your phone talks to servers run by one company. That company stores your posts, decides who sees them and can change the rules tomorrow.

Central design has real strengths. There is one source of truth, so everyone sees the same answer. Updates are fast, because one machine or one team decides. Fixing a bug means changing code in one place. Support is easy because one party owns the whole problem.

The weak points are equally clear. If the center breaks, everyone loses service. If the owner makes a bad decision, changes a price or closes an account, users have little recourse. If an attacker gets into the center, they reach everything at once.

Decentralized Systems

A decentralized system spreads control across several independent parties. No single party can decide alone. Email is a good example. You may use Gmail while a friend uses a university mail server. Both servers follow the same open rules, called protocols, so messages cross between them. No single company runs email as a whole.

Baran's second picture shows this shape: several hubs, each serving its own group, linked to one another. Each hub keeps its own rules inside its own area, and the hubs agree on shared rules between them.

Another example is the banking world. Many banks exist, each controlled by a different owner, and they settle payments with each other through shared standards. Still, each bank is a small centralized system inside the larger network.

Decentralization is therefore a matter of degree. A system with three owners is more decentralized than a system with one, and a system with three thousand independent owners is more decentralized still. The useful question is how many independent parties must fail or cooperate before the system changes.

Distributed Systems

A distributed system is a group of computers, usually in different locations, that cooperate to act like one system. The word describes where the machines are and how they coordinate. It says nothing about who owns them.

A large video service may run thousands of servers in many countries so that viewers get fast streams. The computers are spread out, and they coordinate through message passing, yet one company owns and controls all of them. That makes the service distributed and also centralized in control.

This is the key point of the week: distributed describes the machines, decentralized describes the control. A system can be distributed and centralized (a big tech company's data centers), distributed and decentralized (Bitcoin), or centralized in a single room (a small shop's one server).

Baran's third picture, the fishing net, shows a distributed network. Many paths connect every pair of points, so the loss of one point leaves the others connected. We study how such systems cope with delays and failures in week 2.

Three Kinds Of Decentralization

Vitalik Buterin, a co-founder of Ethereum, wrote an essay in 2017 that splits decentralization into three separate questions. They give you a practical checklist.

Architectural decentralization asks how many physical computers the system is made of, and how many of them can crash before it stops working. Political decentralization asks how many individuals or organizations control those computers. Logical decentralization asks whether the system's data and interface look like one shared object or like a single object that could be cut in half and still work.

These three can differ. A blockchain can run on thousands of machines (architectural), yet if most of those machines are owned by one company, political decentralization is low. A website can run on a single server but let the community vote on all its rules, giving it some political decentralization without architectural spread.

• Architectural: how many machines, and how many can fail
• Political: how many independent owners or decision makers
• Logical: whether one shared state exists, or each part works alone

Three Words Side By Side

	Centralized	Decentralized	Distributed
Who decides	One owner	Several owners	Not defined by this word
Where machines are	Often one place	Anywhere	Many places, linked by a network
Typical failure	Single point of failure	Disputes between owners	Partial failure of machines
Example	A company database	Email between providers	A replicated cloud database

Decentralized and distributed describe different axes: who controls versus where machines sit. Source: Course synthesis

The Trade-Offs

Every design buys some benefits and pays with some costs. No design wins in every row of the table, so a good engineer chooses by the needs of the job.

Centralized systems are usually fastest to build, cheapest to run and easiest to change. They suit most apps. A recipe website with one server and one owner has no reason to become decentralized.

Decentralized and distributed designs offer resilience, because no single failure ends the service. They also reduce the power of any one operator, which matters when users cannot trust that operator. The cost is complexity. Coordinating many independent machines means agreeing on facts, handling delays and dealing with machines that lie or disappear. Those problems fill weeks 2 to 4 of this course.

Speed also changes. A single database answers in milliseconds. A network that must reach agreement between many parties can take seconds or minutes. Cost changes too: duplicating data on many machines uses more storage and bandwidth.

• Centralized: fast, simple, cheap, one point of failure, one point of power
• Decentralized: shared power, harder to shut down, slower to change
• Distributed: scales and survives hardware failure, harder to reason about

Why People Care

People look for decentralized designs when the cost of trusting one operator becomes high. Four reasons come up again and again.

The first is censorship resistance. If one company controls a service, anyone with power over that company can cut a user off. When many independent parties run the service, cutting off a user takes much more effort.

The second is uptime. A system with many operators keeps running when one of them fails. The third is ownership. Users can keep their own data and keys instead of renting access to an account. The fourth is credible neutrality: a rule that nobody can quietly change is a rule that strangers can depend on, which helps people who do not know each other do business.

These benefits matter only when the problem needs them. Throughout this course we will keep asking a calm question: what exactly is the threat, and does a decentralized design address it better than a well-run central one?

A Habit For The Whole Course

Whenever you meet a new system, ask five questions. Who runs the machines? Who can change the rules? What happens if one machine fails? What happens if one operator turns hostile? Who can see the data?

Try it on WhatsApp. One company runs the servers and sets the rules, so control is central. Messages are encrypted, so the company cannot read them, which limits what it can see. If its servers fail, everyone is cut off. Now try it on Bitcoin. Thousands of independent computers keep a shared ledger, and no company can change the rules alone. A single computer failing changes nothing.

Write down your own answers for three services you use. By next week you will have the vocabulary to explain why some of them are hard to build in a decentralized way.

Two Questions To Ask Of Any System

1. Who can change the rules?
2. Where do the machines run?
3. Who can switch it off?
4. What do users lose if one party leaves?

Run these four questions in order on every system you meet in this course.

Key Terms

System

A set of computers and programs that cooperate to do a job.

Centralized

A design where one party holds the data and makes the decisions.

Decentralized

A design where control is shared across several independent parties.

Distributed

A design where many computers in different places cooperate as one system.

Protocol

A set of shared rules that lets different machines communicate.

Single point of failure

One component whose failure stops the whole system.

Censorship resistance

The ability of a service to keep working when someone powerful wants to block it.

Credible neutrality

A property of rules that treat all users the same and cannot be changed quietly.

Trust assumption

A thing you must believe about someone for a system to behave as promised.

Exercise: Classify Five Services

1. Pick five services you use: for example email, WhatsApp, a bank app, a video site and a cryptocurrency wallet.
2. Make a table with these columns: service, who runs the machines, who can change the rules, what happens if one machine fails.
3. Fill in each row using only information you can find on the service's own website or documentation.
4. Mark each service as centralized, decentralized or distributed in two separate columns: one for machines and one for control.
5. Score each service from 1 to 5 on architectural, political and logical decentralization.
6. Write three sentences about the service that surprised you most and keep the table for week 2.

Further Reading

• On Distributed Communications: I. Introduction to Distributed Communications Networks, Paul Baran, RAND Corporation memorandum, 1964
• The Meaning of Decentralization, Vitalik Buterin, essay, 2017
• Distributed Systems, 4th edition (chapter 1), Maarten van Steen and Andrew Tanenbaum
• Designing Data-Intensive Applications (chapter 1), Martin Kleppmann, O'Reilly