Systems Architecture¶

A comprehensive curriculum covering distributed systems fundamentals, asynchronous patterns, microservices design, and the trade-offs every architect must understand to build systems that scale without breaking.

[!NOTE] Topic Overview Systems Architecture covers the full spectrum of concerns in designing software systems that run across multiple machines, communicate asynchronously, and must remain reliable despite partial failures. This is the discipline that separates engineers who can build features from engineers who can build infrastructure that supports millions of users.

This topic is organized into progressive modules, each building on the last. Work through them in order unless you already have relevant prior experience — use the Difficulty & Time Estimate section and the Prerequisites section to decide where to begin.

Table of Contents¶

• Overview
• Historical Context
• Real-World Applications
• Learning Objectives
• Difficulty & Time Estimate
• Prerequisites
• Learning Modules
• Progress
• Milestones
• Test Scores
• Projects
• Resources
• Related Topics
• Quick Reference
• Learning Journal
• AI Metadata

Overview¶

Systems Architecture is the discipline of designing software systems at the level above individual applications — deciding how services communicate, where data lives, how failures are handled, and what trade-offs are acceptable for a given problem. It is the domain where engineering decisions have the largest and longest-lasting consequences.

A distributed system is any system where components run on separate machines and communicate over a network. This definition is deceptively simple: the moment you add a second machine, you inherit an entirely new class of problems. Networks partition. Clocks drift. Processes crash. Operations that were trivially atomic on a single machine become coordination nightmares. The core challenge of systems architecture is not adding features — it is managing the inherent complexity that distribution introduces.

This topic is deliberately nuanced. Monoliths are not inherently bad. Microservices are not inherently good. The right architecture for a 5-person startup is almost certainly wrong for a 500-person engineering organization, and vice versa. The goal of this curriculum is not to teach you a set of rules to follow but to build the judgment to make the right call in context.

Why It Matters¶

Every production application above a certain scale is a distributed system, whether intentionally designed as one or not. A web application talking to a database is already distributed. Add a cache, a background job processor, and a third-party payment provider, and you have a multi-node system with all the associated failure modes.

Understanding systems architecture is valuable because:

• It underpins every backend engineering role at scale — distributed systems knowledge is the single largest distinguishing factor between junior and senior backend engineers
• It develops the mental model for reasoning about failure — a skill that transfers directly to reliability engineering, platform engineering, and technical leadership
• Proficiency in it is expected in roles such as Senior Software Engineer, Staff Engineer, Solution Architect, and Site Reliability Engineer

Key Features of This Topic¶

• Trade-off focused — every pattern is presented with its costs, not just its benefits
• Historically grounded — concepts are explained in the context of the real problems that motivated them
• Pattern-oriented — industry-standard patterns (Saga, Outbox, Circuit Breaker, CQRS) taught at the level of understanding, not just recognition
• Diagram-heavy — Mermaid architecture diagrams and sequence diagrams throughout to build visual intuition

Historical Context¶

The discipline of distributed systems grew from a fundamental tension: single machines have physical limits, but users' demands for data and compute are unbounded.

Timeline¶

Real-World Applications¶

Systems Architecture principles are applied across every technology company:

• Netflix — Migrated from a monolithic DVD-rental application to hundreds of microservices 2009–2015. Pioneered chaos engineering, circuit breakers (Hystrix), and resilience patterns that became industry standards
• Amazon — Jeff Bezos's "API mandate" in 2002 forced all internal systems to communicate only through service interfaces; AWS is the product of Amazon externalizing its internal infrastructure services
• Uber — Moved from a monolith to microservices circa 2014, then to a "domain-oriented microservice architecture" (DOMA) circa 2019 to manage the coordination complexity of thousands of services
• Shopify — Deliberately chose a modular monolith over microservices, citing operational and coordination overhead; their "pods" architecture partitions data and compute while keeping a unified codebase
• Discord — Uses a mix of Go, Rust, and Elixir/Erlang services based on problem characteristics; their engineering blog is a primary source for real-world trade-off documentation
• LinkedIn — Invented Apache Kafka as an internal solution to high-throughput event streaming; open-sourced it in 2011 where it became the dominant distributed log

Learning Objectives¶

By completing this topic in full, you will be able to:

1. Explain the CAP theorem, the PACELC model, and why distributed consistency is fundamentally different from single-machine consistency
2. Design messaging topologies using appropriate delivery semantics (at-most-once, at-least-once, exactly-once) for a given use case
3. Apply the Saga pattern (choreography and orchestration variants), the Outbox pattern, and CQRS to distributed data problems
4. Decompose a monolithic application into microservices using bounded contexts from Domain-Driven Design, with justified service boundary decisions
5. Implement resilience patterns — circuit breaker, bulkhead, retry with exponential backoff — and explain when each is appropriate
6. Design an observability strategy for a distributed system using distributed tracing, structured logging, and metrics aggregation
7. Conduct architecture decision-making using ADRs, trade-off analysis frameworks, and evolutionary architecture principles
8. Build and document a complete distributed system design for a realistic use case, including service decomposition, data ownership, messaging topology, and failure modes

Difficulty & Time Estimate¶

Prerequisites¶

Before starting this topic, you should have a working understanding of:

• [[networks]] — specifically: HTTP request/response lifecycle, TCP vs UDP, DNS basics, what a network packet is
• [[postgresql]] — specifically: transactions (ACID properties), what a database is, basic SQL, why databases are not just file storage
• [[devops-platform-engineering]] — specifically: what a container is, what a load balancer does, basic deployment concepts

[!TIP] Not sure if you're ready? Attempt Module 01 and gauge how it feels. If terms like "network partition", "database transaction", or "HTTP" are entirely foreign, revisit the prerequisites above first. If you can follow along but things feel shaky, press on — it will solidify.

Learning Modules¶

Status key: Not started  ·  ~ In progress  ·  x Complete

Progress¶

Overall Progress¶

[░░░░░░░░░░░░░░░░░░░░] 0 / 12 modules complete (0%)

Update this bar as you complete modules. Each block = 5% of total modules.

Legend:  ░ = not started   ▒ = in progress   █ = complete
Example: [███████▒░░░░░░░░░░░░] 7.5 / 12 modules (37%)

Point Tracker¶

Milestones¶

• First Step — Complete Module 01 (Introduction to Distributed Systems)
• Foundation Built — Complete Modules 01–03 with ≥ 70% on each test
• Halfway There — Complete 6 of 12 modules
• Patterns Expert — Score ≥ 80% on all Modules 02–06 tests
• Architect's Eye — Complete at least one architecture design project
• Topic Complete — All 12 modules finished
• Deep Work — Complete the Capstone Project with documented ADRs
• Chaos Practitioner — Score 100% on Module 09 (Resilience and Chaos)

Test Scores¶

Append a row after each test attempt. Do not overwrite previous attempts.

Grade scale: A ≥ 90%  ·  B ≥ 80%  ·  C ≥ 70%  ·  D ≥ 60%  ·  F < 60%

Projects¶

See PROJECTS.md for project ideas ranging from beginner to expert.

My Projects:

Resources¶

See RESOURCES.md for a curated and verified list of books, courses, videos, and tools.

Top picks so far (fill in as you study):

1. To be filled in
2. To be filled in
3. To be filled in

Related Topics¶

Topics that complement, extend, or are required for Systems Architecture:

• [[networks]] — Network fundamentals are the physical substrate on which all distributed systems run; understanding TCP/IP, latency, and network topologies is essential
• [[devops-platform-engineering]] — Container orchestration, CI/CD, and infrastructure automation are how distributed systems are deployed and operated
• [[graphql-rest]] — API design for service-to-service and client-to-service communication; REST and GraphQL are the dominant protocols for synchronous service calls
• [[postgresql]] — Understanding database transactions, ACID properties, and replication is required for reasoning about data consistency in distributed systems
• [[feature-flags-monitoring]] — Feature flags enable safe rollout of architectural changes; monitoring and alerting are the operational complement to observability design

See also the ROADMAP.md for how this topic fits into broader learning paths.

Quick Reference¶

CAP Theorem Cheat Sheet¶

Distributed Systems Patterns Quick Reference¶

Learning Journal¶

Date-stamp each entry. Write honestly — confusion documented now becomes insight later. Newest entries at the top.

2026-06-09 — Started Topic¶

What I did today: - Read the topic overview and ROADMAP.md - Reviewed prerequisites

What clicked: - Write one thing that made sense immediately

What's still unclear: - Write your first open question — then add it to QUESTIONS.md

How I feel about this topic: - Honest assessment: excited / intimidated / curious / confused / etc.

Add new journal entries above this line, newest first.

AI Metadata¶

# Maintained by LEAPS tooling — manual edits will be overwritten on next sync
last_ai_expansion: "2026-06-09"
topic_slug: "systems-architecture"
topic_name: "Systems Architecture"
module_count: 12
modules_complete: 0
total_points_earned: 0
total_points_possible: 624
completion_percentage: 0
difficulty: "Advanced → Expert"
estimated_hours: 90
prerequisites:
  - "networks"
  - "postgresql"
  - "devops-platform-engineering"
related_topics:
  - "networks"
  - "devops-platform-engineering"
  - "graphql-rest"
  - "postgresql"
  - "feature-flags-monitoring"
tags:
  - "distributed-systems"
  - "microservices"
  - "backend"
  - "architecture"
  - "queues"
  - "async"
creator: "Community"
year_created: "2026"