1. Overview of Decentralized System
A decentralized system is a class of systems without any central coordination or management unit. In other words, there is no single central server to coordinate or manage the system. Decentralized systems have both advantages and disadvantages compared to centralized systems, so which of these two topology archetypes you choose for your system depends on which of the advantages you need or want.
Decentralized systems can be divided into two categories:
Distributed server system
Peer-to-peer (P2P) systems
2. Distributed server system
A distributed server system is a server-side decentralized system of a client-server system. For example, decentralized databases such as Cassandra or MongoDB.
Decentralized server systems typically only decentralize the server portion of the overall system. The overall architecture is still a client-server architecture - some nodes in the system are clients while others are servers.
Examples of decentralized server systems are:
Apache Cassandra
MongoDB
Amazon DynamoDB
3. Peer-to-peer system
A peer-to-peer system (P2P), sometimes called a peer-to-peer network, is a system in which all nodes in the network are both clients and servers. Each node (peer) acts both as a server to provide a service to other nodes (peers) and as a client to consume that service from other nodes. Therefore, all nodes in a peer-to-peer system are peers of each other—meaning the same function and role. The diagram below shows a fully decentralized system where all nodes have the same level of functionality and authority. That's why they are often referred to as peers - equals to each other.
Examples of P2P networks and P2P network algorithms and topologies are:
Chord (algorithm)
Kademlia (algorithm)
Polymorph polyring (algorithm)
Dandelion - The goal is to provide strong, provable anonymity guarantees.
Gnutella - A file sharing protocol that defines a way for distributed nodes to communicate over a peer-to-peer (P2P) network.
4. Blockchain system
Blockchain systems such as Bitcoin, Ethereum, and LBRY also use P2P networks for communication and collaboration. They do this because a blockchain system (like a database) maintains a distributed state, so nodes in a blockchain system need to agree on what that state is.
Note: Some blockchain systems' nodes do not all perform the exact same job/role. For example, some nodes are "validator nodes", while others are "wallet nodes", etc. Such a blockchain system might be classified as a decentralized server system rather than a pure P2P system. What matters, however, is not the classification you give to a given blockchain system. It's important that you understand how it works.
5. Benefits of a decentralized system
Decentralized systems can have some benefits over centralized systems - depending on how these decentralized systems are designed.
Greater flexibility
A well-designed decentralized system can be more resilient than a centralized system because a decentralized system has no single point of failure that can bring the entire system down. If one node in a decentralized system crashes, other nodes in the system can take over.
horizontal scalability
A well-designed decentralized system usually scales well horizontally - meaning scaling by adding more nodes (computers) to the network, rather than having each node use more powerful hardware (vertical scaling).
Reduce hardware costs
P2P networks can sometimes run exclusively and directly on end-user devices (computers, phones, consoles, etc.). In these cases, the end user is contributing the hardware needed to run the system. As a result, creators of software that create P2P networks can save significant hardware costs. They likely won't be able to achieve zero hardware cost -- but probably a lot less than if they had to pay for all the hardware they use to run the system.
6. Decentralized system challenges
Implementing certain types of functionality in a decentralized system is more challenging than in a centralized system.
decentralized consensus
One of the biggest challenges of a decentralized system is reaching consensus on a shared state - if multiple nodes in the system can initiate changes to that state. "State" generally refers to some data stored in data corresponding to a database (ie, a decentralized database).
If two or more nodes in a decentralized system are both trying to change the state of the same logical object, then the system needs to somehow determine in what order the state changes should be applied.
Imagine if two nodes in the system both wanted to change the "name" of the same "client" in a shared state. If the first node wants to change the name to "Satoshi" and the second node wants to change the name to "Vitalik" - which name will the client end up using? This scenario looks like this:
Decentralized consensus, sometimes called distributed consensus, is a broad topic, and there are several different ways to achieve it.
broadcast, multicast, routing and lookup
Depending on the topology of a decentralized system, it can be challenging to effectively and efficiently broadcast or multicast messages to all nodes or a subset of nodes in the network. By practical, I mean making sure that all expected nodes actually receive the message. By efficient I mean no node receives a message more than once. Some models of decentralized broadcasting may be able to guarantee one but not the other.
Similar problems exist in performing efficient message routing and node or data lookups in the system. How do you efficiently discover what other nodes are in the system? How do you efficiently find the location of an object if that object is only stored on one node in the system?
The topology used by a decentralized system has a large impact on these issues. You may have to design the topology of the system to meet your specific needs, rather than using the same general topology for all use cases.