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

Chapter 4. Adapters

In the preceding chapters, we saw how the sidecar pattern can extend and augment existing application containers. We also saw how ambassadors can alter and broker how an application container communicates with the external world. This chapter describes the final single-node pattern: the adapter pattern. In the adapter pattern, the adapter container is used to modify the interface of the application container so that it conforms to some predefined interface that is expected of all applications. For example, an adapter might ensure that an application implements a consistent monitoring interface. Or it might ensure that log files are always written to stdout or any number of other conventions.

Real-world application development is a heterogeneous, hybrid exercise. Some parts of your application might be written from scratch by your team, some supplied by vendors, and some might consist entirely of off-the-shelf open source or proprietary software that you consume as precompiled binary. The net effect of this heterogeneity is that any real-world application you deploy will have been written in a variety of languages, with a variety of conventions for logging, monitoring, and other common services.

Yet, to effectively monitor and operate your application, you need common interfaces. When each application provides metrics using a different format and interface, it is very difficult to collect all of those metrics in a single place for visualization and alerting. ...