The document discusses the principles of reactive applications including responsiveness, resilience, elasticity, and bounded latency. It advocates taking an asynchronous and message-driven approach by distributing work across nodes, handling failures through timeouts and supervision, and scaling capacity up and down to handle changing loads. This results in applications that can respond quickly even in the face of failures or load changes. Developers are encouraged to embrace asynchrony and loose coupling between components to build reactive systems.
28. Handle Load
• partition incoming work for distribution
• share nothing
• scale capacity up and down on demand
• supervise and adapt
• location transparency
➟ seamless scalability
14
29. Handle Load
• partition incoming work for distribution
• share nothing
• scale capacity up and down on demand
• supervise and adapt
• location transparency
➟ seamless scalability
14
m
31. Consequences
• distribution & scalability
➟ loss of strong consistency
• CAP theorem? — not as relevant as you think
• eventual consistency
➟ gossip, heartbeats, dissemination of change
!
16
32. Consequences
• distribution & scalability
➟ loss of strong consistency
• CAP theorem? — not as relevant as you think
• eventual consistency
➟ gossip, heartbeats, dissemination of change
!
16
m
35. Step 1: Take a Leap of Faith
• thread-based models have made us defensive
• “don’t let go of your thread!”
• “asynchrony is suspicious”
• “better return strict value, even if that needs blocking”
19
36. Step 1: Take a Leap of Faith
• thread-based models have made us defensive
• “don’t let go of your thread!”
• “asynchrony is suspicious”
• “better return strict value, even if that needs blocking”
• it is okay to write a method that returns a Future!
19
37. Step 2: Rethink the Architecture
• break out of the synchronous blocking prison
• focus on communication & protocols
• asynchronous program flow
➟ no step-through debugging
➟ tracing and monitoring
• loose coupling
20
38. Step 3: Profit!
• clean business logic,
separate from failure handling
• distributable units of work
• effortless parallelization
21
39. Step 3: Profit!
• clean business logic,
separate from failure handling
• distributable units of work
• effortless parallelization
• less assumptions ➟ lower maintenance cost
21