# d-sys.wiki

**d-sys.wiki** is your home for all things [distributed systems](/fundamentals).

## purpose

this wiki was created to be easily consumed by humans and [ai](/llms.txt) to enhance distributed systems skills.

## features

in addition to simple casual explanations on how to architect and build distributed systems, **d-sys.wiki** provides:

- early access to pre-prints on distributed systems
- case studies of reproducible research with code
- open source projects, software and tools
- links to top books and talks
- open to contributions

...and more! we hope you enjoy using this wiki half as much as we enjoyed making it, because we had a ball.

# Creative Commons Legal Code

## CC0 1.0 Universal

```
CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
HEREUNDER.

```

## Statement of Purpose

The laws of most jurisdictions throughout the world automatically confer exclusive Copyright and Related Rights (defined below) upon the creator and subsequent owner(s) (each and all, an "owner") of an original work of authorship and/or a database (each, a "Work").

Certain owners wish to permanently relinquish those rights to a Work for the purpose of contributing to a commons of creative, cultural and scientific works ("Commons") that the public can reliably and without fear of later claims of infringement build upon, modify, incorporate in other works, reuse and redistribute as freely as possible in any form whatsoever and for any purposes, including without limitation commercial purposes. These owners may contribute to the Commons to promote the ideal of a free culture and the further production of creative, cultural and scientific works, or to gain reputation or greater distribution for their Work in part through the use and efforts of others.

For these and/or other purposes and motivations, and without any expectation of additional consideration or compensation, the person associating CC0 with a Work (the "Affirmer"), to the extent that he or she is an owner of Copyright and Related Rights in the Work, voluntarily elects to apply CC0 to the Work and publicly distribute the Work under its terms, with knowledge of his or her Copyright and Related Rights in the Work and the meaning and intended legal effect of CC0 on those rights.

1. Copyright and Related Rights. A Work made available under CC0 may be protected by copyright and related or neighboring rights ("Copyright and Related Rights"). Copyright and Related Rights include, but are not limited to, the following:

i. the right to reproduce, adapt, distribute, perform, display, communicate, and translate a Work; ii. moral rights retained by the original author(s) and/or performer(s); iii. publicity and privacy rights pertaining to a person's image or likeness depicted in a Work; iv. rights protecting against unfair competition in regards to a Work, subject to the limitations in paragraph 4(a), below; v. rights protecting the extraction, dissemination, use and reuse of data in a Work; vi. database rights (such as those arising under Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, and under any national implementation thereof, including any amended or successor version of such directive); and vii. other similar, equivalent or corresponding rights throughout the world based on applicable law or treaty, and any national implementations thereof.

1. Waiver. To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer's heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer's express Statement of Purpose.
1. Public License Fallback. Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose. In addition, to the extent the Waiver is so judged Affirmer hereby grants to each affected person a royalty-free, non transferable, non sublicensable, non exclusive, irrevocable and unconditional license to exercise Affirmer's Copyright and Related Rights in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "License"). The License shall be deemed effective as of the date CC0 was applied by Affirmer to the Work. Should any part of the License for any reason be judged legally invalid or ineffective under applicable law, such partial invalidity or ineffectiveness shall not invalidate the remainder of the License, and in such case Affirmer hereby affirms that he or she will not (i) exercise any of his or her remaining Copyright and Related Rights in the Work or (ii) assert any associated claims and causes of action with respect to the Work, in either case contrary to Affirmer's express Statement of Purpose.
1. Limitations and Disclaimers.

a. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document. b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law. c. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work. d. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work.

# distributed systems fundamentals

## what are distributed systems?

**distributed systems** are networks of independent computers (nodes) communicating through message passing, collaboratively delivering unified services or achieving shared objectives. each node maintains its own memory, processing capability, and local storage, working concurrently and autonomously. nodes interact through standardized protocols and interfaces, allowing the system to function effectively across geographic distances, network delays, and varied hardware or software platforms.

the primary advantages of distributed systems include:

- **scalability**: ability to handle growing workloads by adding more resources
- **fault tolerance**: continuing operation despite component failures
- **resilience**: recovering from failures automatically
- **efficient resource utilization**: optimizing use of computing resources across the network

these systems range from small local networks to globe-spanning cloud infrastructures, powering everything from web applications to financial systems and massive data processing pipelines.

## the cap theorem

distributed systems embody three essential properties described by the **cap theorem**, formulated by eric brewer in 1998:

- **consistency**: ensuring all nodes have a synchronized and accurate view of data. when a write operation completes, all subsequent read operations should reflect that write.
- **availability**: providing reliable access and responses to user requests. every request to a non-failing node must receive a response, without guaranteeing it contains the most recent write.
- **partition tolerance**: maintaining operation despite network partitions or node failures. the system continues functioning even when network communication between some nodes is unreliable.

the cap theorem dictates that no system can simultaneously achieve all three properties at full strength. system architects must strategically balance these properties based on specific application requirements:

- **cp systems** (consistency + partition tolerance): prioritize data consistency at the potential cost of availability during partitions. examples include traditional banking systems and distributed databases like google spanner.
- **ap systems** (availability + partition tolerance): favor availability over strict consistency. examples include nosql databases like amazon dynamodb and cassandra.
- **ca systems** (consistency + availability): optimize for both properties but cannot handle network partitions effectively. these systems are theoretical in distributed environments, as partition tolerance is generally required.

## distributed system architectures

distributed systems employ diverse architectural patterns to address varying use cases:

### client-server architecture

centralizes resource management with dedicated servers responding to client requests. this architecture is ideal for predictable workloads and clear separation of concerns.

**characteristics**:

- clear separation between service providers (servers) and consumers (clients)
- centralized resource management
- relatively simple to implement and understand

**examples**: traditional web applications, email services, file servers

### peer-to-peer (p2p) architecture

distributes responsibilities evenly among equivalent nodes, improving resilience and scalability. each node can act as both client and server.

**characteristics**:

- no centralized control
- high resilience to node failures
- excellent scalability
- complex coordination requirements

**examples**: bittorrent, blockchain networks, distributed file systems

### microservices architecture

decomposes applications into loosely coupled, independent services, streamlining development and deployment. each service handles a specific function and can be developed, deployed, and scaled independently.

**characteristics**:

- service independence
- technology diversity
- focused development teams
- complex orchestration

**examples**: netflix, amazon, uber applications

### event-driven architecture

utilizes asynchronous communication via events or messages, enhancing flexibility and responsiveness. components react to events rather than direct calls.

**characteristics**:

- loose coupling between components
- asynchronous processing
- enhanced scalability
- complex debugging and testing

**examples**: iot systems, real-time analytics platforms, financial trading systems

### service-oriented architecture (soa)

encapsulates functionalities into reusable, interoperable services with standardized interfaces. this approach emphasizes service reusability and composition.

**characteristics**:

- business-aligned services
- standardized interfaces
- service reusability
- enterprise service bus (often)

**examples**: enterprise integration systems, banking platforms

## core components of distributed systems

typical distributed system components include:

| component | role | example technologies | | --- | --- | --- | | **load balancer** | evenly distribute client requests across servers to optimize resource utilization, maximize throughput, and ensure high availability | aws elb, nginx, haproxy, f5 | | **message queue** | enable asynchronous communication between services, providing buffering, decoupling, and reliable message delivery | apache kafka, rabbitmq, aws sqs, azure service bus | | **database (relational)** | store structured data with acid properties, supporting complex queries and transactions | postgresql, mysql, oracle, sql server | | **database (nosql)** | provide flexible, schema-less data storage optimized for specific data models and high scalability | mongodb, cassandra, dynamodb, couchbase | | **cache** | store frequently accessed data in memory to reduce latency and database load | redis, memcached, hazelcast | | **orchestration platform** | automate deployment, scaling, and management of containerized services | kubernetes, docker swarm, aws ecs, nomad | | **service discovery** | enable services to find and communicate with each other dynamically | consul, etcd, zookeeper | | **api gateway** | provide a unified entry point for clients, handling cross-cutting concerns like authentication and rate limiting | kong, amazon api gateway, apigee | | **consensus algorithm** | achieve agreement on shared state across distributed nodes | paxos, raft, zab | | **distributed tracing** | track and visualize request flows across multiple services for debugging and monitoring | jaeger, zipkin, aws x-ray |

## key design considerations

designing robust distributed systems requires addressing several critical concerns:

### performance optimization

- **latency**: minimize response time through caching, cdns, and optimized data access patterns
- **throughput**: maximize system capacity through horizontal scaling and efficient resource utilization
- **network efficiency**: reduce bandwidth consumption with compression, batching, and protocol optimization

### consistency models

- **strong consistency**: all nodes see the same data at the same time (e.g., linearizability)
- **eventual consistency**: system will become consistent given enough time without updates
- **causal consistency**: operations that are causally related appear in the same order to all nodes
- **session consistency**: client operations in a session are consistent with their own operations

### data management

- **replication strategies**: synchronous vs. asynchronous, active-active vs. active-passive
- **sharding approaches**: range-based, hash-based, directory-based partitioning
- **data synchronization**: conflict detection and resolution mechanisms

### fault tolerance and recovery

- **failure detection**: heartbeats, gossip protocols, and health checks
- **redundancy**: multiple instances, geographic distribution, and standby systems
- **graceful degradation**: maintaining core functionality during partial system failures
- **self-healing mechanisms**: automated recovery and repair procedures

### security considerations

- **authentication and authorization**: verifying identity and controlling access rights
- **encryption**: protecting data at rest and in transit
- **network segmentation**: limiting attack surfaces through isolation
- **audit logging**: recording security-relevant events for compliance and forensics

### monitoring and observability

- **metrics collection**: gathering performance and health indicators
- **distributed tracing**: following requests across service boundaries
- **log aggregation**: centralizing and analyzing system logs
- **alerting**: detecting and notifying about critical conditions