Foreword: DSM's Value and the Learning Path

A recurring distributed-systems risk is treating a local guarantee as if it were a global one. A successful local write does not mean that a remote node can already read it, and eventual replica convergence does not revoke business responses that have already been returned.

DSM is a distributed shared memory foundation for Java applications. It shares coordination state—such as route hints, shard ownership, and mergeable counters—across service instances. A single Runtime provides state identity, typed collections, local operations, online propagation, conflict handling, and replica repair. Teams can reuse these defined and tested mechanisms instead of implementing propagation, merge, and repair logic in every service.

That value has clear limits. Eventual convergence does not provide transactional consistency, and replica repair does not replay a complete business-event history. Orders, inventory, and payments retain their authoritative systems. Application teams still define business invariants, partition behavior, external fencing or idempotency, and the security and capacity standards of the deployment environment.

The book follows a distributed order-fulfillment control plane:

• The route-hints Register stores service routing hints.
• The shard-owners Lease manages shard ownership.
• The request-counter CRDT merges request counts from multiple nodes.

The six arcs form one continuous path. Arc 1 identifies suitable shared state and creates a Runtime. Arc 2 selects Register, Lease, or CRDT from business invariants. Arc 3 explains online propagation, loss, repair, and partition boundaries. Arc 4 integrates DSM through a domain adapter and Spring Boot. Arc 5 adds observability, security, lifecycle, and capacity responsibilities. Arc 6 tests the conclusions through real ports, federation, technology rejection, and a capstone.

Each chapter introduces a problem before its mechanism. The experiment acceptance card records the command, observable result, evidence level, and uncovered scope. After completing the book, a developer should be able to adopt or reject DSM for a particular state and defend that decision with code, fault experiments, and runtime evidence.

Continue with Chapter 1 to decide which states belong in DSM.