Distributed systems is a higher-order level of systems design problems. It's a field of study that looks at how agents (typically computers/nodes, but in principle it could be people) act in conjunction with one another to achieve the goal of the [[System of Systems]].
While distributed systems is typically a computer-specific paradigm in my reading, it "feels" like something that can and does absolutely apply in **human** systems. All of the [[#Distributed Systems Values, Principles, and Methods Values & Principles]] feel like they could easily be applied to workers at a business.
# Examples
Things I've noted that were build to function in a distributed way:
- [[Kafka]]
- [[Block Chain]]
- Stub notes:
- [[Big Data]]
- [[MongoDB]]
# Topics
## Distributed Systems [[Values, Principles, and Methods| Values & Principles]]
| [[Values, Principles, and Methods\|Values]] | [[Principles Index\|Principles]] |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Concurrency** | Components within the system operate at the same time, enabling parallel processing |
| **Fault Tolerance** | The overall system should continue to operate even when some components fail. Ideally there is no single point of failure. |
| **Scalability** | The system should be able to scale to huge workloads, very preferably through the addition of more nodes rather than more compute within a node |
| **Consistency** | The components of the system should tell the same story about the state of the system and its data, i.e. component X should not different from component Y if they both are asked about component Z. |
| **Modularity** | The system should be built to be [[Highly Cohesive, Loosely Coupled]] |
| **Independence** | The components of the system should be able to operate, grow, and be improved largely independent of the system as a whole. |
| **Paritioning** | Large workloads should be broken down into smaller, more manageable chunks which can be operated on by multiple nodes simultaneously. |
| **Coordination** | Different parts of the system should harmonize to make the system work better, rather than discordantly disagree with (or fight with) one-another. |
## Architectures
### Network Distribution Type
- **Client-Server** - you have servers providing services and clients requesting them communicating to each other over a network
- The clear separation of roles is what distinguishes client-server architectures
- **Peer-to-Peer** - similar to client-server, but every peer functions as both the client and the server for each other
- **Multi-tier** - a variant of client-server in which the services are segregated into tiers, for example you could have a user-facing tier, a data-accessing tier, and a tier of middleware
- Websites and applications often function in a 3-tiered way (the [[Model, View, Controller Pattern]])
### Design Approach
- **Service-Oriented** - this is essentially the [[De Facto]] approach to organization nowadays, it seems. Perhaps the only way something could be **not** service-oriented would be if its one monolithic process (like a mainframe or something)
- **Microservices** - this is a refinement of the service-oriented architecture wherein services are broken down into smaller parts - rather than a service handling data storage, authentication, and presentation, you might have 3 separate services to compose that capability
- This promotes reusability & [[Modularity]] - you could for example use the one authentication service across all the places its needed
- **[[Event-Driven Architecture]]** - rather than nodes responding to messages, instead they fire off and respond to *events*.
****
# More
## Source
- https://en.wikipedia.org/wiki/Distributed_computing
- mentors
- grad school
- Distributed Systems by Maarten van Steen