Learning to Build Reliable Systems - ToC
Perfect — this is a very good pause point, and you’re right to do this before continuing further.
Below is the entire ToC, cleaned, frozen, and rewritten as a single coherent syllabus, with 2–4 explanatory lines per chapter, written explicitly for engineers new to FBP, DDD, BEAM, Phoenix, and JSON modelling.
This version is canonical — you can reuse it for:
blog series
internal docs
onboarding
teaching material
talks
No code assumptions. Concept-first. Flow-first.
📚 **Learning to Build Reliable Systems Using
Flow-Based Programming, JSON Modelling, and Stateless BEAM**
A beginner-friendly, concept-first journey from “working code” to production-safe systems.
Part I — Resetting How Engineers Think About Systems
Goal: Break old mental models gently and build production intuition.
Chapter 1 — Why Many “Working” Systems Still Fail in Production
Explains why systems that work in dev and demo collapse in real-world conditions. Introduces production realities: partial failure, retries, concurrency, and cascading outages — without technical jargon.
Chapter 2 — Why Thinking in Functions and APIs Is Not Enough
Shows the limits of function-centric and request–response thinking once concurrency and failure enter the system. Explains why clean code alone doesn’t guarantee safe execution.
Chapter 3 — Introducing Flow-Based Thinking
Introduces the idea that systems are flows of work, not stacks of function calls. Builds the core mindset shift without mentioning BEAM, JSON, or frameworks.
Chapter 4 — What Does “A Flow” Mean in Practice?
Uses everyday processes (approvals, onboarding, orders) to explain flows, transitions, handoffs, and responsibility boundaries in a concrete, intuitive way.
Part II — Flow-Based Programming (FBP) from First Principles
Goal: Teach FBP as a problem-solving method, not a technology.
Chapter 5 — What Is Flow-Based Programming (FBP)?
Defines FBP in simple terms: independent components, explicit connections, and moving packets of work. Clarifies what FBP is — and what it is not.
Chapter 6 — Components, Connections, and Responsibilities
Explains how to identify independent components, assign responsibilities, and avoid accidental coupling between parts of the system.
Chapter 7 — Why FBP Avoids Shared State by Design
Explains the dangers of shared state and how FBP structurally prevents it, rather than relying on discipline or conventions.
Chapter 8 — Designing Systems That Expect Failure
Introduces failure as a normal operating condition. Shows how FBP naturally supports retries, restarts, and recovery without chaos.
Chapter 9 — Classic FBP vs Modern Cloud-Native FBP
Explains how FBP adapts to stateless containers, Kubernetes, and horizontal scaling — and why this is an evolution of FBP, not a compromise.
Part III — Learning to Solve Problems Using FBP
Goal: Apply flow thinking before touching code.
Chapter 10 — Turning a Problem Statement into a Flow Diagram
A step-by-step method to convert vague requirements into clear flows with components and transitions.
Chapter 11 — Identifying Inputs, Outputs, and Transitions
Teaches how to define clear entry points, exits, and intermediate transitions so flows remain understandable and controllable.
Chapter 12 — Handling Branches, Fan-Out, and Aggregation
Introduces common flow patterns such as branching, parallel work, and result aggregation using simple, real-world examples.
Chapter 13 — Making Failure and Retries Explicit in the Flow
Shows how retries, fallback paths, and compensations must be designed explicitly — never hidden inside code.
Part IV — JSON as the Language of Flows
Goal: Introduce modelling before execution.
Chapter 14 — Why We Model Systems Using JSON
Explains JSON as a modelling and communication language, not just a data format. Shows why explicit models protect systems over time.
Chapter 15 — Modelling Domain Data with JSON
Introduces domain entities, aggregates, and identities using simple JSON structures that reflect real business meaning.
Chapter 16 — Modelling Actions and Events with JSON
Explains the difference between data and intent: commands vs events, requests vs outcomes.
Chapter 17 — JSON Schemas as Contracts
Shows how schemas act as contracts between components, enforce boundaries, and prevent silent system drift.
Part V — Domain-Driven Design (DDD) Without Microservices
Goal: Teach DDD correctly, gently, and safely.
Chapter 18 — What Problem Is DDD Actually Solving?
Explains DDD as a response to complexity, ambiguity, and miscommunication — not as a microservices strategy.
Chapter 19 — Bounded Contexts Explained Simply
Introduces bounded contexts using everyday examples (payments, onboarding, inventory) and explains why boundaries matter.
Chapter 20 — Nanoservices: DDD Inside a Single Runtime
Introduces nanoservices as small, domain-owned components living inside one BEAM instance — without network overhead.
Chapter 21 — Enforcing Domain Rules Without Shared State
Shows how domain invariants live inside nanoservices even when persistence is external and the runtime is stateless.
Part VI — Enter BEAM: Executing Flows Safely
Goal: Introduce BEAM as an execution engine for flows.
Chapter 22 — Why We Need a Runtime That Protects Us
Explains what a runtime does and why BEAM’s process model is fundamentally different from threads and locks.
Chapter 23 — BEAM Processes as Flow Components
Maps FBP components directly to BEAM processes and explains why this mapping is natural and safe.
Chapter 24 — Message Passing as the Only Way Components Talk
Explains how message passing enforces boundaries, eliminates shared state, and makes systems easier to reason about.
Chapter 25 — Supervision: Making Failure Boring
Introduces OTP supervision as structured recovery, not exception handling or defensive coding.
Chapter 26 — Stateless BEAM: Why It Works Better
Explains why BEAM instances are stateless, restartable, and horizontally scalable — and why this is a strength.
Part VII — Phoenix, REST, and Persistence
Goal: Connect to familiar web and database concepts.
Chapter 27 — Phoenix as an Entry and Exit Point
Explains Phoenix controllers as adapters that translate HTTP into internal flows, not as business logic containers.
Chapter 28 — REST at the Edge, Flows Inside
Shows how HTTP requests become internal JSON messages and why REST belongs only at system boundaries.
Chapter 29 — CockroachDB as Durable Memory
Explains persistence, transactions, and why databases store facts but must not orchestrate workflows.
Chapter 30 — Persistence as a Domain Responsibility
Shows how database access itself becomes a nanoservice owned by a domain, not a shared utility.
Part VIII — Building a Complete System Step by Step
Goal: Integrate everything into one mental model.
Chapter 31 — Designing a Full System Using Only Models
Starts from requirements and designs the entire system using flows, JSON models, and domain boundaries — without code.
Chapter 32 — Executing the Design Inside a Single BEAM Instance
Shows how the model runs safely using OTP processes and supervision inside one stateless BEAM runtime.
Chapter 33 — Scaling with Kubernetes Without Changing the Model
Explains how horizontal scaling works when BEAM instances are stateless and flows are explicit.
Chapter 34 — Observability Through Flow Visibility
Shows how logs, metrics, and tracing become natural when flows and boundaries are explicit.
Part IX — Engineering Discipline and Growth
Goal: Make the architecture sustainable for teams.
Chapter 35 — Rules Every Engineer Must Follow
Defines hard rules: no shared state, schema ownership, idempotency, thin controllers, explicit flows.
Chapter 36 — Common Anti-Patterns and How to Spot Them
Highlights beginner mistakes and how to detect architectural drift early.
Chapter 37 — How Junior Engineers Become Productive Quickly
Explains why this model is safe, teachable, and forgiving for new engineers.
Chapter 38 — Why This Architecture Scales Over Years
Focuses on long-term evolution, clarity, and resilience — not benchmarks or hype.
Epilogue — From Writing Code to Designing Systems
Reframes engineering as system design and responsibility modelling, not framework usage.