Learning Resources
This module is populated from the local chunked books in library/raw/semester-08-system-design-leadership/books and a curated set of canonical external references. Use this page as a source map, not as an instruction to read everything. Each concept file already carries its targeted "Read This Only If Stuck" list; this page is the module-wide index that explains why those sources exist and how to navigate between them.
Source Stack
| Source | Role | How to use it in this module |
|---|---|---|
| Fundamentals of Software Architecture (Richards & Ford), Ch. 14 | Primary teaching source | Default escalation for broker/mediator topology, async capabilities, request-reply over events, data loss prevention |
| System Design Primer (Martin, open source) | Selective support | Short reinforcements on asynchronism, queues, consistency/availability patterns, cache update patterns, communication styles |
| Designing Event-Driven Systems (Ben Stopford, O'Reilly) | Extended narrative | Use the free PDF for Kafka-as-platform reasoning and stream processing framing |
| Building Microservices (Sam Newman) | Cross-module support | Ch. on async comms; most microservices-specific event material is in S8M2 |
| Designing Data-Intensive Applications (Kleppmann) | Deep dive | S6 path; here used only if you want depth on replication, stream processing, and delivery semantics |
| Martin Fowler's event-driven essays | Canonical framing | Single best short reference for the four lenses (notification, ECST, sourcing, CQRS) |
| Chris Richardson's microservices.io pattern language | Pattern catalog | Default entry point for Saga, Outbox, CQRS, Event Sourcing, Idempotent Consumer |
| Greg Young, CQRS Documents | CQRS/ES origin | Long-form write-up from the person who named modern CQRS |
| Alberto Brandolini, EventStorming | Discovery workshop | The practical way to derive a clean event list before code |
Primary Chunks from Fundamentals of Software Architecture (Ch. 14)
These are the chunks this module leans on most heavily. Open them first when you need depth.
| Chunk | Concept home | Why |
|---|---|---|
| 041 -- Event-Driven Architecture Style | C1-C5 (foundational) | Broker vs mediator topology; initiating vs processing events |
| 042 -- Mediator Topology | C4 (orchestration) | The orchestrator's place in the topology and its tradeoffs |
| 043 -- Asynchronous Capabilities | C1, C2, C3 | Why event-driven is naturally fire-and-forget; response-time framing |
| 044 -- Preventing Data Loss | C2 (outbox), C3 (brokers), C4 (sagas), C5 (ES) | Durability, acks, DLQ design -- the through-line for reliable events |
| 045 -- Request-Reply | C1 (commands), C4 (orchestration) | Sync-over-async mechanics when you truly need a reply |
| 046 -- Event-Driven Ratings | C3, C5 | Scalability/elasticity/evolvability ratings EDA earns and pays for |
| 049 -- Data Collisions | C3 (ordering), C4 (idempotency) | Concurrent-update failure modes that show up in consumer design |
Primary Chunks from System Design Primer
| Chunk | Concept home | Why |
|---|---|---|
| 18 -- Asynchronism | C1, C2, C3, C4 | The compact queue / task-queue / back-pressure framing; reappears in every cluster |
| 05 -- Consistency patterns | C3 (event-driven state), C4 (sagas), C5 (projections/CQRS) | Eventual-consistency vocabulary EDA runs on |
| 06 -- Availability patterns | C2 (ECST), C3, C4 | Why independent subscribers and outbox-backed publish improve the availability envelope |
| 17 -- Cache update patterns | C5 (projections) | Comparison substrate for "projection as derived, eventually-consistent view" |
| 13 -- Database federation / sharding | C3 (partitions) | Sharding analogy for Kafka partition keys and hot partitions |
| 21 -- Communication: RPC / REST | C1 (events vs requests) | Synchronous end of the spectrum; contrast for when sync is the better tool |
Resource Map by Cluster
Cluster 1: Events as a Mental Model
| Need | Best resource | Why |
|---|---|---|
| The mental model: event vs request | Richards & Ford: Event-Driven Architecture Style | Contrasts request-based and event-based models with worked examples |
| Async posture | Richards & Ford: Asynchronous Capabilities | Why event-driven is naturally fire-and-forget |
| Disentangling "event-driven" | Fowler: What do you mean by "Event-Driven"? | The four-lens essay; the single most clarifying reference |
| Events as a domain primitive | Microservices.io: Domain events and Fowler: Domain Event | Compact pattern entries that tie event to DDD |
| Event message vs command message | EIP: Event Message and Command Message | The 2003-vintage canonical definitions |
| Command/query separation origin | Fowler: Command Query Separation | Meyer's principle extended to service messaging |
| CRUD-to-events mental shift | System Design Primer: Asynchronism + Confluent: It's Okay To Store Data In Kafka | Short, operational framing + Kafka-as-storage argument |
| Discovery / workshop practice | Alberto Brandolini: EventStorming | Forces teams to model in past-tense facts |
| Deep dive (optional) | Kleppmann: Turning the Database Inside Out (talk) and Kleppmann: Stream Processing / Event Sourcing / Reactive / CEP | 50-min lecture + essay that reframe DBs as caches of a log |
Cluster 2: Messaging Patterns
| Need | Best resource | Why |
|---|---|---|
| Pub-sub vs point-to-point | System Design Primer: Asynchronism + EIP: Publish-Subscribe Channel + Point-to-Point Channel | Canonical delivery-model references |
| Fanout in production | AWS: Fanout SNS -> SQS and AWS: Event-driven architecture overview | The "pub-sub in front, point-to-point behind" pattern made concrete |
| Notification vs ECST | Fowler: Event-Carried State Transfer + Event Notification + EIP: Document Message | Source of the terms plus the older EIP term for ECST |
| Schema governance for ECST | Confluent: Schema Registry overview | The operational backbone ECST usually needs |
| Outbox pattern | Microservices.io: Transactional outbox + Polling publisher + Transaction log tailing | Three related pattern entries covering relay variants |
| Outbox in practice | Confluent: Transactional Outbox course + Debezium: Outbox event router + Debezium: PostgreSQL connector | The production-grade CDC implementation |
| Durability tradeoffs | Richards & Ford: Preventing Data Loss | Broker persistence and consumer acks |
| Availability framing | System Design Primer: Availability patterns | Why ECST-style payloads can keep consumers alive when producer is sick |
Cluster 3: Brokers and Log-Based Systems
| Need | Best resource | Why |
|---|---|---|
| Queue semantics | AWS SQS Developer Guide + Visibility timeout + Dead-letter queues | Hosted-queue canonical references with the two most-often-misconfigured knobs broken out |
| AMQP model | RabbitMQ: AMQP 0-9-1 Model | Exchanges, queues, bindings |
| DLQ and work-distribution patterns | EIP: Dead Letter Channel + Competing Consumers | Canonical definitions for queue operations |
| Kafka design | Apache Kafka: Documentation -- Design + Consumer configs + Design: Consumers | Log-structured replicated design and consumer positioning |
| Kafka retention and compaction | Apache Kafka: Compaction + Confluent: Kafka retention explained | Retention/compaction mechanics with operational guidance |
| Kafka introduction | Confluent: Apache Kafka 101 | Friendly walkthrough with diagrams |
| Consumer groups and rebalancing | Confluent: Consumer Groups Explained + Incremental Cooperative Rebalancing + Cooperative Rebalancing (Streams, ksqlDB) + KIP-848 | Progressive depth: membership, modern rebalance protocol, next-generation protocol |
| Broker topology framing | Richards & Ford: Event-Driven Architecture Style | Where brokers sit in the architecture |
| Ratings (async characteristics) | Richards & Ford: Event-Driven Ratings | How EDA rates on characteristics |
| Partitioning as sharding | System Design Primer: Federation/sharding | The sharding analogy that carries over to Kafka partitioning |
| Foundational essays | Jay Kreps: The Log + Confluent: It's Okay To Store Data In Kafka | Why log-based design matters and why the log is durable storage |
Cluster 4: Distributed Workflow with Events
| Need | Best resource | Why |
|---|---|---|
| Choreography vs orchestration | Richards & Ford: Mediator Topology | Central coordinator discussion with tradeoffs |
| Request-reply over events | Richards & Ford: Request-Reply | Sync-over-async mechanics |
| Saga pattern (both variants) | Microservices.io: Saga pattern | Canonical treatment |
| Saga on AWS | AWS: Saga orchestration pattern + Saga pattern (modernization guide) + Serverless saga with Step Functions + Compute blog walkthrough | Prescriptive guidance and runnable reference |
| Saga with Temporal | Temporal: Saga pattern made easy + Compensating actions + Temporal docs | Code-first orchestration reference |
| Saga historical depth | Garcia-Molina & Salem: SAGAS (1987 paper) | Foundational paper; optional |
| Modern saga practice | Caitie McCaffrey: Applying the Saga Pattern (talk) | Reviving the pattern for microservices |
| Hybrid collaboration | Bernd Rücker: Why service collaboration needs choreography AND orchestration | Practical hybrid advice from Camunda co-founder |
| Idempotency | Microservices.io: Idempotent consumer + EIP: Idempotent Receiver | Pattern entries |
| Honest "exactly once" | Confluent: Exactly-once Semantics Are Possible | Explains boundaries of EOS |
| Idempotency on external APIs | Stripe: Idempotent requests + AWS SQS: FIFO exactly-once processing | Canonical Idempotency-Key contract and AWS's narrower flavor |
Cluster 5: Event Sourcing and CQRS
| Need | Best resource | Why |
|---|---|---|
| Event sourcing concept | Fowler: Event Sourcing + Fowler: Event-Driven State | Canonical essay + the "events-as-state" lens |
| Microservices framing | Microservices.io: Event sourcing | Pattern treatment |
| CQRS concept | Fowler: CQRS + Fowler: Command Query Separation | Short, clear, with deliberate warnings; origin of the name |
| CQRS pattern | Microservices.io: CQRS pattern | Entry with pros/cons |
| Projections practice | Fowler: Reporting Database + Fowler: Eager Read Derivation + Confluent: Materialized views with ksqlDB + Confluent: Unifying stream processing and interactive queries | The "derived view" heritage and the Kafka-native how |
| Stream processing | Kafka Streams: Stateful operations | One way to implement projections |
| Classic lecture | Greg Young: CQRS and Event Sourcing (talk) + CQRS Documents PDF | Defined the modern practice; long-form companion |
| Retrospective | Greg Young: A Decade of DDD, CQRS, Event Sourcing | Cautions and refinements |
| Event store reference | EventStoreDB: What is event sourcing? | Concrete implementation framing from a purpose-built event store vendor |
Video and Lecture Lane
- Martin Kleppmann: Turning the Database Inside Out -- the best single lecture for the event-log-as-truth shift (~50 min)
- Caitie McCaffrey: Applying the Saga Pattern -- sagas for modern microservices (~45 min)
- Greg Young: CQRS and Event Sourcing -- the canonical CQRS+ES talk (~60 min)
- Greg Young: A Decade of DDD, CQRS, Event Sourcing -- retrospective cautions (~60 min)
- Ben Stopford: The Data Dichotomy -- Kafka as the integration backbone (~35 min)
- Jay Kreps: Kafka and the Log -- shorter companion to his essay (~30 min)
Book Lane
- Stopford, Designing Event-Driven Systems (O'Reilly, free PDF from Confluent) -- event-driven at platform scale.
- Richardson, Microservices Patterns -- Ch. on saga, outbox, event sourcing, CQRS; extends this module.
- Newman, Building Microservices (2nd ed.) -- async communication chapter as a companion.
- Kleppmann, Designing Data-Intensive Applications -- stream processing and replication (S6 path; deep dive only).
- Vernon, Implementing Domain-Driven Design -- domain events as a DDD primitive (pairs with S7M3).
- Young, CQRS Documents (free PDF) -- the original 2010 long-form write-up.
External Source Directory
Grouped by author/vendor for quick lookup when writing ADRs, RFCs, or design reviews.
Martin Fowler (martinfowler.com)
- What do you mean by "Event-Driven"? -- four-lens essay
- Event Sourcing
- CQRS
- Domain Event
- Command Query Separation
- Reporting Database
- Eager Read Derivation
Chris Richardson (microservices.io)
- Pattern language index · Saga · CQRS · Event sourcing · Domain event · Transactional outbox · Polling publisher · Transaction log tailing · Idempotent consumer
Confluent (blog + learn + developer)
- Storage: It's Okay To Store Data In Kafka · Kafka retention explained
- Consumers & rebalancing: Consumer Groups Explained · Incremental Cooperative Rebalancing · Cooperative Rebalancing (Streams, ksqlDB) · KIP-848
- Delivery semantics: Exactly-once Semantics
- Projections / read models: Materialized views with ksqlDB · Unifying stream processing and interactive queries
- Integration: Transactional Outbox (developer course) · Kafka 101 · Schema Registry
Apache Kafka (kafka.apache.org)
AWS
- Event-driven overview: Event-driven architecture · EventBridge: What Is · EventBridge concepts
- SNS/SQS: SQS Developer Guide · Visibility timeout · DLQ · FIFO exactly-once · SNS->SQS fanout
- Saga: Orchestration pattern · Modernization saga · Step Functions saga · Compute blog walkthrough
Debezium
Temporal
Greg Young
Alberto Brandolini / EventStorming
Martin Kleppmann
- Turning the Database Inside Out (talk) · Stream processing, Event sourcing, Reactive, CEP… · The Log (Kreps, LinkedIn Engineering)
Enterprise Integration Patterns (EIP)
- Event Message · Command Message · Document Message · Publish-Subscribe Channel · Point-to-Point Channel · Dead Letter Channel · Competing Consumers · Idempotent Receiver
Payment APIs (idempotency reference)
Use Rules
- If you are stuck on the mental model, Fowler's four-lens essay and Richards & Ford Ch. 14 are the first escalations.
- For operational Kafka details, go straight to the Kafka docs; third-party tutorials vary wildly in quality. Confluent's engineering blog is the reliable second choice.
- For sagas, microservices.io is the canonical pattern entry; Rücker's blog and the AWS/Temporal vendor docs are the best second opinions.
- For CQRS and event sourcing, read Fowler first for the framing and Greg Young second for the origin-of-the-practice detail. The vendor docs (EventStoreDB, Confluent/Kafka Streams) come later and only for implementation specifics.
- Open one chunk for one gap; do not wander through a whole chapter sequence by default.
- Prefer official docs (Kafka, SQS, EventBridge, Debezium, Temporal, Stripe) over third-party summaries for implementation details.
- Every concept file lists its own "Read This Only If Stuck" block with 8-12 refs. Use this page when you need a cross-concept map; use the concept file when you need a targeted escalation.