System Design Space
Knowledge graphSettings

Updated: May 11, 2026 at 11:16 AM

Designing Distributed Systems (short summary)

medium

This book matters because it makes distributed systems tangible through small composable building blocks rather than through abstract diagrams of ten services.

In real design work, the chapter shows how neighboring containers, local mediators, request fan-out, work queues, and batch processing combine into practical flows.

In interviews and engineering discussions, it helps present patterns as a way to simplify a system without hiding the real constraints and weak spots behind them.

Practical value of this chapter

Design in practice

Build distributed flows from small patterns with clear ownership boundaries.

Decision quality

Stress-test patterns for idempotency, safe retries, and observability in complex processing chains.

Interview articulation

Explain the design through neighboring containers, local mediators, adapters, queues, and request fan-out.

Trade-off framing

Call out when patterns truly reduce complexity and when they only mask deeper system issues.

Related book

Kubernetes Patterns

A pattern catalog for application lifecycle, configuration, Jobs, and Kubernetes operators.

Read review

Designing Distributed Systems

Authors: Brendan Burns
Publisher: O'Reilly Media, 2018
Length: 162 pages

A review of Brendan Burns's book: composable distributed-system patterns for Pod composition, replication, sharding, scatter/gather, work queues, and team responsibility.

Original
Translated

This chapter treats distributed systems not as abstract diagrams of ten services, but as a set of composable patterns: Pod and container composition, Sidecar, Ambassador, Adapter, replicated services, sharding, Scatter/Gather, work queues, event-triggered batch processing, and responsibility tables. That vocabulary helps discuss architecture through reusable building blocks rather than a random collection of Kubernetes manifests.

Documentaries

Book structure

Single-Node Patterns

Patterns for one node: Sidecar, Ambassador, and Adapter. The key idea is container composition inside a single Pod.

Multi-Node Patterns

Serving patterns across multiple nodes: replication, sharding, and scatter/gather.

Batch Patterns

Work queues, event-triggered batch processing, and coordination of multi-step computational workflows.

Single-node patterns

These patterns organize multiple containers next to the application so cross-cutting behavior stays separate from core business logic.

Sidecar Pattern

The Sidecar pattern adds a neighboring container that extends the application without changing its code.

Where it fits:

  • Log shipping with Fluentd or Filebeat
  • Configuration synchronization with git-sync
  • TLS termination close to the application

Pod

App
business logic
+
Sidecar
logs, TLS, config

Two containers share one Pod lifecycle but own different responsibilities.

Ambassador Pattern

The Ambassador pattern hides external connection details behind a local mediator inside the Pod.

Where it fits:

  • Database connection pooling
  • A service mesh mediator such as Envoy
  • Circuit breaking for a problematic external dependency
App
local call
Ambassador
connection policy
External DB
address, TLS, retries

The local mediator hides connection details

Adapter Pattern

The Adapter pattern reshapes an application's output into the format expected by the platform or observability tools.

Where it fits:

  • Metrics export for Prometheus
  • Log format normalization
  • A wrapper around a legacy API without rewriting the application
Legacy app
native format
Adapter
normalization
Prometheus
common metrics

Format and metrics normalization

Multi-node serving patterns

Deep dive

Designing Data-Intensive Applications, 2nd Edition

DDIA on replication, sharding, and consistency guarantees.

Read review

Replicated Load-Balanced Services

A replicated service runs identical instances behind load balancing. It is the baseline path for scaling stateless services.

horizontal scalinghigh availabilityrolling updates
Load balancing
Replica A
Replica B
Replica C

Sharded Services

A sharded service splits data across nodes by key: each shard owns a range or hash space.

Where it fits:

  • Hashing a key when the data is evenly distributed
  • Ranges by time, region, or another natural dimension
  • Explicit handling for hot keys, rebalancing, and cross-shard queries
Router
Shard A
A-F
Shard B
G-N
Shard C
O-Z

Scatter/Gather Pattern

Scatter/Gather sends a request to several nodes in parallel and merges partial responses into one result.

Coordinator
Node 1
Node 2
Node 3
Result merge

Useful for search, analytics, and other cases where a distributed query beats one large sequential pass.

Batch computational patterns

Related book

Building Microservices

Sam Newman on business-process coordination and service interaction.

Read review

Work Queue Systems

The producer-consumer pattern puts work items into a queue, while workers consume them in parallel.

Where it fits:

  • The source creates tasks
  • The queue smooths different rates between stages
  • Workers scale independently of the source
Source
Queue
Worker 1
Worker 2
Worker 3

Event-Driven Batch Processing

Event-driven batch processing starts a job when a file, queue message, or webhook appears.

serverless functionsKubernetes Jobsevent-driven architecture
Event
Trigger
Batch job

New file, webhook, or queue message

Coordinated Batch Processing

Coordinated batch processing connects multiple stages with dependencies, retries, and explicit workflow state.

Extract
Transform
Load
Merge

Commonly implemented with workflow engines such as Airflow, Argo Workflows, or Temporal.

Team responsibility and functions as a service

Hands-Off Table

A responsibility table shows which team owns a component, who supports it, and who gets called during an incident.

Team A
Team B
API Gateway
owns
supports
Payments
supports
owns
Data Lake
owns
-

FaaS Decorator Pattern

A FaaS decorator adds cross-cutting concerns such as access checks, logging, and rate limiting.

Function
Access
Logs
Rate limit

Functions add cross-cutting behavior around a service

Applying it in system design interviews

Useful concepts

  • Sidecar for cross-cutting concerns
  • Ambassador for service mesh integration
  • Sharded services for data and traffic growth
  • Scatter/Gather for parallel search and analytics
  • Work queues for batch processing

Where it helps

  • How would you add log collection without changing application code?
  • How would you scale a stateful service?
  • How would you implement distributed search?
  • How would you process millions of events without overwhelming consumers?

Main takeaways

Single-node patterns start with container composition.
Replicated services are the simplest path to horizontal growth.
Sharding is needed when one node can no longer hold the data volume or request flow.
Scatter/Gather can speed up distributed queries.
Work queues improve batch-processing reliability through explicit buffering.
A good pattern reduces coupling, while a poor fit adds operational complexity.

Related chapters

Where to find the book

Enable tracking in Settings