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