book

Designing Distributed Systems

by Brendan Burns

February 2018

Intermediate to advanced

162 pages

4h 8m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Who Should Read This BookWhy I Wrote This BookThe World of Distributed Systems TodayNavigating This BookConventions Used in This BookOnline ResourcesUsing Code ExamplesO’Reilly SafariHow to Contact UsAcknowledgments
A Brief History of Systems DevelopmentA Brief History of Patterns in Software DevelopmentFormalization of Algorithmic ProgrammingPatterns for Object-Oriented ProgrammingThe Rise of Open Source SoftwareThe Value of Patterns, Practices, and ComponentsStanding on the Shoulders of GiantsA Shared Language for Discussing Our PracticeShared Components for Easy ReuseSummary
MotivationsSummary
An Example Sidecar: Adding HTTPS to a Legacy ServiceDynamic Configuration with SidecarsModular Application ContainersHands On: Deploying the topz ContainerBuilding a Simple PaaS with SidecarsDesigning Sidecars for Modularity and ReusabilityParameterized ContainersDefine Each Container’s APIDocumenting Your ContainersSummary
Using an Ambassador to Shard a ServiceHands On: Implementing a Sharded RedisUsing an Ambassador for Service BrokeringUsing an Ambassador to Do Experimentation or Request SplittingHands On: Implementing 10% Experiments
MonitoringHands On: Using Prometheus for MonitoringLoggingHands On: Normalizing Different Logging Formats with FluentdAdding a Health MonitorHands On: Adding Rich Health Monitoring for MySQL
Introduction to Microservices
Stateless ServicesReadiness Probes for Load BalancingHands On: Creating a Replicated Service in KubernetesSession Tracked ServicesApplication-Layer Replicated ServicesIntroducing a Caching LayerDeploying Your CacheHands On: Deploying the Caching LayerExpanding the Caching LayerRate Limiting and Denial-of-Service DefenseSSL TerminationHands On: Deploying nginx and SSL TerminationSummary
Sharded CachingWhy You Might Need a Sharded CacheThe Role of the Cache in System PerformanceReplicated, Sharded CachesHands On: Deploying an Ambassador and Memcache for a Sharded CacheAn Examination of Sharding FunctionsSelecting a KeyConsistent Hashing FunctionsHands On: Building a Consistent HTTP Sharding ProxySharded, Replicated ServingHot Sharding Systems
Scatter/Gather with Root DistributionHands On: Distributed Document SearchScatter/Gather with Leaf ShardingHands On: Sharded Document SearchChoosing the Right Number of LeavesScaling Scatter/Gather for Reliability and Scale

Determining When FaaS Makes SenseThe Benefits of FaaSThe Challenges of FaaSThe Need for Background ProcessingThe Need to Hold Data in MemoryThe Costs of Sustained Request-Based ProcessingPatterns for FaaSThe Decorator Pattern: Request or Response TransformationHands On: Adding Request Defaulting Prior to Request ProcessingHandling EventsHands On: Implementing Two-Factor AuthenticationEvent-Based PipelinesHands On: Implementing a Pipeline for New-User Signup
Determining If You Even Need Master ElectionThe Basics of Master ElectionHands On: Deploying etcdImplementing LocksHands On: Implementing Locks in etcdImplementing OwnershipHands On: Implementing Leases in etcdHandling Concurrent Data Manipulation
A Generic Work Queue SystemThe Source Container InterfaceThe Worker Container InterfaceThe Shared Work Queue InfrastructureHands On: Implementing a Video ThumbnailerDynamic Scaling of the WorkersThe Multi-Worker Pattern
Patterns of Event-Driven ProcessingCopierFilterSplitterSharderMergerHands On: Building an Event-Driven Flow for New User Sign-UpPublisher/Subscriber InfrastructureHands On: Deploying Kafka
Join (or Barrier Synchronization)ReduceHands On: CountSumHistogramHands On: An Image Tagging and Processing Pipeline

Content preview from Designing Distributed Systems

Part I. Single-Node Patterns

This book concerns itself with distributed systems, which are applications made up of many different components running on many different machines. However, the first section of this book is devoted to patterns that exist on a single node. The motivation for this is straightforward. Containers are the foundational building block for the patterns in this book, but in the end, groups of containers co-located on a single machine make up the atomic elements of distributed system patterns.

Motivations

Though it is clear as to why you might want to break your distributed application into a collection of different containers running on different machines, it is perhaps somewhat less clear as to why you might also want to break up the components running on a single machine into different containers. To understand the motivation for these groups of containers, it is worth considering the goals behind containerization. In general, the goal of a container is to establish boundaries around specific resources (e.g., this application needs two cores and 8 GB of memory). Likewise, the boundary delineates team ownership (e.g., this team owns this image). Finally, the boundary is intended to provide separation of concerns (e.g., this image does this one thing).

All of these reasons provide motivation for splitting up an application on a single machine into a group of containers. Consider resource isolation first. Your application may be made up of two components: ...