- Front Matter
- Cover — 1
- Preface - The Boundary the First Volume Reached — 2-4
- Contents — 5-8
- PART I — CONCURRENCY INSIDE ONE PROCESS — 9
- Chapter 1 — Concurrency, Parallelism, and Asynchrony Are Different — 10
- Chapter 2 — Shared Memory Means Shared Correctness — 38
- Chapter 3 — The .NET Memory Model: Visibility, Ordering, and Happens-Before — 64
- Chapter 4 — Locks, Monitors, and Critical Sections — 91
- Chapter 5 — Atomics, Interlocked, and Compare-and-Swap — 120
- Chapter 6 — False Sharing, Cache Lines, and Contended State — 151
- Chapter 7 — The ThreadPool: Work Without One Thread Per Operation — 178
- Chapter 8 — ThreadPool Injection, Hill-Climbing, and Starvation — 206
- Chapter 9 — Task Is Work, Not a Thread — 234
- Chapter 10 — async/await as a State Machine — 262
- Chapter 11 — SynchronizationContext, TaskScheduler, and Continuation Placement — 290
- Chapter 12 — Bounded Concurrency, Cancellation, and Backpressure — 318
- Visual I — One Process, Many Logical Operations — 343
- PART II — I/O AND THE PROCESS BOUNDARY — 348
- Chapter 13 — Blocking I/O and Completion-Based I/O — 349
- Chapter 14 — Windows IOCP, Linux Readiness, and the Abstraction Above Them — 372
- Chapter 15 — Buffers, Copies, Pinning, and the Cost of Moving Bytes — 393
- Chapter 16 — What IPC Actually Is — 417
- Chapter 17 — Shared Memory Between Processes — 433
- Chapter 18 — Anonymous Pipes and Named Pipes — 452
- Chapter 19 — Unix Domain Sockets and Local Sockets — 473
- Chapter 20 — Message-Based IPC and Explicit Ownership — 493
- Chapter 21 — Serialization: An Object Does Not Cross the Boundary — 513
- Chapter 22 — Framing, Buffering, Streaming, and Message Boundaries — 533
- Chapter 23 — From Local IPC to a Network Socket — 554
- Visual II — Same Machine, Different Address Spaces — 573
- PART III — THE NETWORK BOUNDARY — 574
- Chapter 24 — A Network Is Not a Faster Function Call — 575
- Chapter 25 — IP: Addressing and Delivery Without Application Meaning — 593
- Chapter 26 — TCP: A Byte Stream With State — 611
- Chapter 27 — Connection Establishment, Loss, Retransmission, and Flow Control — 628
- Chapter 28 — UDP: What You Gain by Giving Up the Stream — 645
- Chapter 29 — DNS: Naming Is Part of Runtime Behaviour — 663
- Chapter 30 — TLS: Identity, Confidentiality, Integrity, and Handshakes — 683
- Chapter 31 — HTTP/1.1: Requests Over Reused Connections — 701
- Chapter 32 — HTTP/2: Multiplexing Changes the Bottleneck — 719
- Chapter 33 — gRPC: Contracts, Streaming, Deadlines, and Status — 741
- Chapter 34 — Connection Pools, Ephemeral Ports, and Client Lifetime — 762
- Visual III — Request -> DNS -> TCP -> TLS -> HTTP -> Response — 783
- PART IV — DISTRIBUTED FAILURE, TIME, AND RESPONSIBILITY — 784
- Chapter 35 — Latency Budgets, Deadlines, and Timeout Composition — 785
- Chapter 36 — Partial Failure: The Other Process May Be Alive but Unreachable — 804
- Chapter 37 — Retries: Repeating an Attempt Is Not Repeating Reality — 823
- Chapter 38 — Idempotency and Stable Operation Identity — 843
- Chapter 39 — Duplicate Delivery, Redelivery, and At-Least-Once Effects — 865
- Chapter 40 — Queues and Brokers: Moving Responsibility Through Time — 884
- Chapter 41 — Backpressure Across a Network Boundary — 902
- Chapter 42 — Ordering, Concurrency, and the Myth of One Global Sequence — 923
- Chapter 43 — Consistency, Staleness, and Read Models — 945
- Chapter 44 — Correlation, Causation, Logs, Metrics, and Distributed Traces — 970
- Chapter 45 — The Boundary Ledger: When Distribution Has Actually Earned Its Cost — 997
- Visual IV — One Call vs One Distributed Interaction — 1025
- Glossary — 1026
- Sources and References — 1038
- Index — 1042
FROM RUNTIME TO DISTRIBUTION
VOLUME II
Cross the process boundary with a systems-level guide to concurrency, async I/O, IPC, TCP, TLS, HTTP/2, gRPC, retries, queues, consistency, observability, and the real cost of distribution.
Minimum price
$80.00
$129
You pay
Author earns
PDF
About
About the Book
What changes when execution leaves one address space?
In Volume I of From Runtime to Distribution, the journey moved downward through the machine beneath .NET: CPU execution, operating-system boundaries, processes, threads, the CLR, IL, JIT compilation, native code, stacks, heaps, and garbage collection.
Volume II begins at the exact point where that local mental model stops being enough.
The moment execution crosses a process boundary, software acquires a new set of physical and semantic constraints. Memory is no longer shared automatically. Objects cannot simply cross the boundary. Calls become messages. Waiting becomes network latency. Failure becomes partial. A timeout no longer tells you whether an operation happened. A retry can repeat an attempt without repeating the same reality.
From Runtime to Distribution — Volume II: Crossing the Process Boundary develops the engineering model required to reason about that transition.
The book begins inside a single process with concurrency, parallelism, and asynchrony. It separates Tasks from threads, examines shared-memory correctness, the .NET memory model, locks, atomics, false sharing, ThreadPool behavior, starvation, async/await state machines, continuation placement, cancellation, and bounded concurrency.
The journey then reaches the process boundary itself.
Blocking and completion-based I/O are examined alongside Windows IOCP and Linux readiness mechanisms. Buffers, copies, pinning, shared memory, anonymous and named pipes, Unix domain sockets, message-based IPC, serialization, framing, streaming, and ownership are treated as parts of one larger question:
How does responsibility move when another address space must participate?
From there, the book crosses the network boundary.
IP is separated from application meaning. TCP is treated as a stateful byte stream rather than a magical reliable pipe. Connection establishment, retransmission, flow control, UDP, DNS, TLS, HTTP/1.1, HTTP/2, gRPC, connection pooling, ephemeral ports, and client lifetime are connected into one end-to-end execution path.
The purpose is not merely to explain protocols.
It is to show how those protocols change software architecture.
The final part turns to the consequences that define distributed systems in practice: latency budgets, deadlines, partial failure, retries, idempotency, duplicate delivery, queues, brokers, backpressure, ordering, consistency, staleness, read models, logs, metrics, and distributed traces.
A timeout is treated as an observation, not proof that nothing happened.
A retry is treated as a new attempt against a world that may already have changed.
Idempotency is developed as a business guarantee based on stable operation identity, not as middleware configuration.
At-least-once delivery is separated from at-least-once business effects.
Ordering is scoped rather than assumed to be global.
Consistency is defined in terms of what a reader is actually allowed to observe.
Backpressure is followed across transport, service, queue, and dependency boundaries instead of being reduced to one buffer or one protocol feature.
Observability becomes an evidence model for reconstructing causation across processes.
The volume ends with the Boundary Ledger: a practical engineering framework for deciding whether a distributed boundary has actually earned its cost.
Independent deployment, independent scaling, failure isolation, security boundaries, ownership, latency, retries, ordering, consistency, backpressure, data authority, operational burden, and reversibility are treated as evidence to be evaluated—not as automatic arguments for microservices.
Four visual checkpoints compress the major transitions:
- One Process, Many Logical Operations
- Same Machine, Different Address Spaces
- Request → DNS → TCP → TLS → HTTP → Response
- One Call vs One Distributed Interaction
The result is a bridge between runtime knowledge and distributed architecture.
From Runtime to Distribution — Volume II is written for .NET developers, software architects, technical leads, and engineers who want to understand what distribution actually changes before designing systems around services, queues, brokers, RPC, or microservices.
The central question of the volume is simple:
When we cross a process boundary, has distribution actually earned everything it costs?
Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.
Author
About the Author
Grigorios Agathangelidis
My name is Grigorios Agathangelidis, and my professional background is in Electrical Engineering and Software Engineering. Much of my work has focused on .NET, distributed systems, software architecture, domain modeling, and the engineering of systems whose behaviour must remain understandable beyond the abstractions provided by frameworks.
From Runtime to Distribution grew from a question that became increasingly important as software architecture moved from single applications toward services, containers, queues, brokers, and distributed systems:
How confidently can we design a distributed system if we do not understand what changes when execution crosses a process boundary?
Volume I approached that question from below. It followed execution through the CPU, operating system, processes, threads, CLR, IL, JIT compilation, native code, stacks, heaps, and garbage collection.
Volume II continues from that foundation and moves outward.
Once execution leaves one address space, assumptions that were cheap or implicit inside one process become explicit engineering contracts. Memory becomes serialization. Function calls become protocols. Waiting becomes latency. Failure becomes partial. Retries introduce duplicate possibilities. Ordering becomes scoped. Read models can become stale. Queues transfer responsibility through time. Observability must reconstruct a history that no single process can see completely.
My broader engineering approach is strongly influenced by the idea that abstractions are useful only while their boundaries remain understood.
Frameworks and distributed platforms allow us to build systems with remarkable speed, but terminology does not remove physical constraints. A remote method call still crosses a network. A message still has ownership and delivery semantics. A timeout still represents incomplete knowledge. A retry can still duplicate an irreversible effect. A queue can absorb a burst but cannot create infinite capacity.
For that reason, I try to separate what a system appears to do from what its runtime, operating system, protocol, and persistence boundaries actually guarantee.
This book is part of the wider NEXUS-1 body of work, which explores complex systems through software architecture, systems engineering, simulation, causal reasoning, domain-driven design, distributed systems, and formal methods. Across that work, I try to preserve the same principle: separate what is modeled from what is measured, what is specified from what is demonstrated, and what an abstraction promises from what the underlying system can actually guarantee.
I approach these subjects primarily as an engineer rather than as an academic specialist in networking or distributed-systems theory. Where behaviour depends on a platform, runtime, protocol version, broker, database, or implementation, I try to identify that boundary rather than turn one implementation detail into a universal law.
The goal of From Runtime to Distribution is not to persuade readers that distributed systems are inherently better than monoliths, or that microservices are the natural destination of mature software.
It is to make the cost of crossing a boundary visible enough that the decision can be made deliberately.
For me, Volume II represents the second major step in that journey: from understanding what executes inside one process to understanding what changes when another process must participate.
Because before asking how many services a system should contain, I believe an engineer should first ask a harder question:
Which boundaries have actually earned the right to exist?
Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.
Contents
Table of Contents
Get the free sample chapters
Click the buttons to get the free sample in PDF or EPUB, or read the sample online here
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earned over $15 million writing, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
Write and Publish on Leanpub
You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!
Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.
Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.