Reactive Design Patterns
Roland Kuhn and Jamie Allen
  • MEAP began March 2014
  • Publication in Early 2016 (estimated)
  • ISBN 9781617291807
  • 325 pages (estimated)
  • printed in black & white

Reactive Design Patterns is a clearly-written guide for building message-driven distributed systems that are resilient, responsive, and elastic. In it, you'll find patterns for messaging, flow control, resource management, and concurrency, along with practical issues like test-friendly designs. All patterns include concrete examples using Scala and Akka. In some cases, you will also see examples in Java, JavaScript, and Erlang. Software engineers and architects will learn patterns that address day-to-day distributed development problems in a fault-tolerant and scalable way. Project leaders and CTOs will gain a deeper understanding of the reactive design philosophy.

Table of Contents show full

Part 1 INTRODUCTION

1. An Illustrated Example

1.1. Geographic Partitioning

1.2. Planning the Flow of Information

1.2.1. First Step: Accepting the Data

1.2.2. Second Step: Getting the Data to their Geographical Home

1.2.3. Step Three: Relocating the Data for Efficient Querying

1.2.4. Taking Stock

1.3. What if something fails?

1.3.1. A Client Fails

1.3.3. A Data Ingestion Front-End Node Fails

1.3.5. A Map Tile Processing Node Fails

1.3.6. A Summary Map Tile Fails

1.3.8. A Map View Front-End Node Fails

1.3.9. Failure Handling Summary

1.4. What have we Learnt from this Example?

1.5. WHere do we go from here?

2. Why Reactive

2.1. Systems and their Users

2.2. Reacting to Users

2.2.1. Responsiveness in a Synchronous System

2.2.2. Why is responsiveness now more important than ever?

2.2.3. Cutting Down Latency by Parallelization

2.2.4. Choosing the Right Algorithms for COnsistent Latency

2.2.5. Bounding Latency even when Things go Wrong

2.2.6. Summarizing the Why and How of Responsiveness

2.3. Reacting to Failure

2.3.1. COmparmentalization and Bulkheading

2.3.2. COnsequences of Distribution

2.3.3. Delegating Failure Handling

2.3.4. Summarizing the Why and How of Resilience

2.4. Reacting to Load

2.4.1. Determining Service Capacity

2.4.2. Building an Elastic Service

2.4.3. Summarizing the Why and How of Scalability

2.5. Reacting to Inputs

2.5.1. Loose Coupling

2.5.2. Better Resource Utilization

2.5.3. Summarizing the Why and How of Event Orientation

2.6. How does this Change the Way We Program?

2.6.1. The Loss of Strong Consistency

2.6.2. The Need for Reactive Design Patterns

2.6.3. Bringing Programming Models Closer to the Real World

2.7. Summary

3. Tools of Trade

3.1. The Impact of Choosing Non-Reactive Tools

3.1.1. The Cost

3.2. Functional Programming

3.2.1. Immutability

3.2.2. Side Effects

3.2.3. Referential Transparency

3.2.4. Functions as First-Class Citizens

3.3. Responsiveness to Users

3.3.1. The Cost of Abstractions

3.3.2. Throughput

3.3.3. Latency

3.3.4. Footprint

3.3.5. Prioritizing the Performance Characteristics

3.4. Implementations That Support Reactive

3.4.1. Green Threads

3.4.2. Event Loops

3.4.3. Communicating Sequential Processes

3.4.4. Futures and Promises

3.4.5. Reactive Extensions

3.4.6. The Actor Model

3.4.7. Summary

Part 2 THE PHILOSOPHY IN A NUTSHELL

4. Message Passing

4.1. Synchronous vs. Asynchronous

4.2. Event-Based vs. Message-Based

4.3. Flow Control

4.4. Delivery Guarantees

4.5. Vertical Scalability

4.6. Events as Messages

4.7. Synchronous Message Passing

4.8. Summary

5. Location Transparency

5.1. What is Location Transparency?

5.2. The Fallacy of Transparent Remoting

5.3. Explicit Message Passing to the Rescue

5.4. The Role of Latency and Throughput

5.5. The Role of Message Loss

5.6. Horizontol Scalability

5.7. Location Transparency makes Testing Simpler

5.8. Dynamic Composition

5.9. Summary

6. Divide and Conquer

6.1. Hierarchical Problem Decomposition

6.2. Dependencies vs. Descendant Modules

6.3. Advantages for Specification and Test

6.4. Build your own Big Corporation

6.5. Horizontal and Vertical Scalability

6.6. Summary

7. Principled Failure Handling

7.1. Ownership means Commitment

7.2. Ownership implies Lifecycle Control

7.3. Resilience on All Levels

7.4. Summary

8. Delimited Consistency

8.1. Encapsulated Modules to the Rescue

8.2. Grouping Data and Behavior According to Transaction Boundaries

8.3. Modeling Work-flows across Transactional Boundaries

8.4. Unit of Failure = Unit of Consistency

8.5. Segregation of Responsibilities

8.6. Persisting Isolated Scopes of Consistency

8.7. Summary

9. Non-Determinism by Need

9.1. Logic Programming and Declarative Data-Flow

9.2. Functional Reactive Programming

9.3. Shared-Nothing Concurrency

9.4. Shared-State Concurrency

9.5. So, What Should We Do?

9.6. Summary

10. Message Flow

10.1. Push Data Forward

10.2. Model the Processes of Your Domain

10.3. Identify Resilience Limitations

10.4. Estimate Rates and Deployment Scale

10.5. Plan for Flow Control

10.6. Summary for Part 2

Part 3 PATTERNS

11. Testing Reactive Applications

11.1. How To Test

11.1.1. Unit Tests

11.1.2. Component Tests

11.1.3. String Tests

11.1.4. Integration Tests

11.1.5. User Acceptance Tests

11.1.6. Black Box Versus White Box Tests

11.2. Test Environment

11.3. Testing Asynchronously

11.3.1. Providing Blocking Message Receivers

11.3.2. The Crux with Choosing Timeouts

11.3.3. Asserting the Absence of a Message

11.3.4. Providing Synchronous Execution Engines

11.3.5. Asynchronous Assertions

11.3.6. Fully Asynchronous Tests

11.3.7. Asserting the Absence of Asynchronous Errors

11.4. Testing Non-Deterministic Systems

11.4.1. The Trouble with Execution Schedules

11.4.2. Testing Distributed Components

11.4.3. Mocking Actors

11.4.4. Distributed Components

11.5. Testing Elasticity

11.6. Testing Resilience

11.6.1. Application Resilience

11.6.2. Infrastructure Resilience

11.7. Testing Responsiveness

11.8. Summary

12. Fault Tolerance and Recovery Patterns

12.1. The Simple Component Pattern

12.1.1. The Problem Setting

12.1.2. Applying the Pattern

12.1.3. The Pattern Revisited

12.1.4. Applicability

12.2. The Let-It-Crash Pattern

12.2.1. The Proactive Failure Signal Pattern

12.3. The Error Kernal Pattern

12.3.1. The Problem Setting

12.3.2. Applying the Pattern

12.3.3. The Pattern Revisited

12.3.4. Applicability

12.4. The Circuit Breaker Pattern

12.4.1. The Problem Setting

12.4.2. Applying the Pattern

12.4.3. The Pattern Revisited

12.4.4. Applicability

12.5. The Active-Passive Replication Pattern

12.5.1. The Problem Setting

12.5.2. Applying the Pattern

12.5.3. The Pattern Revisited

12.6. Multiple-Master Replication Patterns

12.6.1. Consensus-Based Replication

12.6.2. Replication with Conflict Detection and Resolution

12.6.3. Conflict-Free Replicated Data Types

12.7. The Active-Active Replication Pattern

12.7.1. The Problem Setting

12.7.2. Applying the Pattern

12.7.3. The Pattern Revisited

12.7.4. The Relation to Virtual Synchrony

12.8. Summary

13. Resource Management Patterns

14. Message Flow Patterns

15. Flow Control Patterns

16. Persistence Patterns

17. Patterns for Writing Actors

About the Technology

Modern distributed applications must deliver near-realtime performance while at the same time managing big data and high user loads spread across environments ranging from cloud systems to mobile devices. Unlike traditional enterprise applications which focus on decoupling their internal components by defining programming interfaces, reactive applications go one step further and decouple their components also at runtime. This makes it possible to react effectively and efficiently to failures, varying user demands, and changes in the application's execution environment. The resulting systems are highly concurrent and fault-tolerant, with minimal dependencies among individual system components. This is achieved by blending the use of message-passing concurrency between distributed computational units with the robustness of functional programming techniques within them.

About the book

The design patterns in this book were collected by the consultants and engineers of Typesafe during thousands of hours spent building enterprise-quality applications using Scala and Akka. Although many reactive patterns can be implemented using standard development tools like Java, others require the capabilities offered by a functional programming language like Scala and an Actor-based concurrency system like Akka.

What's inside

  • Learn about reactive system design entails and the theory behind its principles
  • Discover best practices and patterns for building reactive applications
  • Build applications that can withstand hardware or software failure at any level
  • Fully utilize multicore hardware using asynchronous and message-driven solutions
  • Scale applications under tremendous load up and down, in and out

About the reader

Readers should be familiar with a standard programming language like Java, C++ or C# and be comfortable with the basics of distributed systems. Although most of the book's examples use the Scala language, no prior experience with Scala or Akka is required.

About the authors

Dr. Roland Kuhn leads the Akka team at Typesafe. Together with Martin Odersky and Erik Meijer, Roland presented the Coursera course "Principles of Reactive Programming" and co-authored the Reactive Manifesto. Jamie Allen is the Director of Consulting for Typesafe and author of Effective Akka.


Manning Early Access Program (MEAP) Read chapters as they are written, get the finished eBook as soon as it’s ready, and receive the pBook long before it's in bookstores.
MEAP combo $49.99 pBook + eBook
MEAP eBook $39.99 pdf + ePub + kindle

FREE domestic shipping on three or more pBooks