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.

1. Go Reactive
Event-Driven, Scalable, Resilient & Responsive Systems
Mirco Dotta
@mircodotta

2. The Four Reactive Traits
Reactive
Applications
2
http://reactivemanifesto.org/

3. Starting Point:
The User

4. The User browser

5. browser
frontend
server
internal
service storage
internal
service
DB
external
service

6. Responsiveness
!
always available
interactive
(near) real-time

7. Bounded Latency
6

8. Bounded Latency
• fan-out in parallel and aggregate
6

9. Bounded Latency
• fan-out in parallel and aggregate
6
A B C

10. Bounded Latency
• fan-out in parallel and aggregate
6
A
B
C

11. Bounded Latency
• fan-out in parallel and aggregate
6
A
B
C
e

12. Bounded Latency
• fan-out in parallel and aggregate
• use circuit breakers for graceful degradation
7

13. Bounded Latency
• fan-out in parallel and aggregate
• use circuit breakers for graceful degradation
7
do work
fail fast

14. Bounded Latency
• fan-out in parallel and aggregate
• use circuit breakers for graceful degradation
• use bounded queues, measure flow rates
8

15. Bounded Latency
• fan-out in parallel and aggregate
• use circuit breakers for graceful degradation
• use bounded queues, measure flow rates
8
Use Bounded Queues:
!
Latency = QueueLength • ProcessingTime
!
(for reasonably stable average processing time)

16. Bounded Latency
• fan-out in parallel and aggregate
• use circuit breakers for graceful degradation
• use bounded queues, measure flow rates
8
Use Bounded Queues:
!
Latency = QueueLength • ProcessingTime
!
(for reasonably stable average processing time)
m

17. Resilience
!
Responsive in the Face of Failure

18. Handle Failure
• software will fail
• hardware will fail
• humans will fail
• system still needs to respond ➟ resilience
10

19. Distribute!
11

20. Asynchronous Failure
• parallel fan-out & distribution
➟ asynchronous execution
• compartmentalization & isolation
• no response? ➟ timeout events
• someone else’s exception? ➟ supervision
12

21. Asynchronous Failure
• parallel fan-out & distribution
➟ asynchronous execution
• compartmentalization & isolation
• no response? ➟ timeout events
• someone else’s exception? ➟ supervision
12

22. Asynchronous Failure
• parallel fan-out & distribution
➟ asynchronous execution
• compartmentalization & isolation
• no response? ➟ timeout events
• someone else’s exception? ➟ supervision
12
Request
Response
Failure

23. Asynchronous Failure
• parallel fan-out & distribution
➟ asynchronous execution
driven
message-• compartmentalization & isolation
• no response? ➟ timeout events
• someone else’s exception? ➟ supervision
12
Request
Response
Failure

24. Asynchronous Failure
• parallel fan-out & distribution
➟ asynchronous execution
• compartmentalization & isolation
• no response? ➟ timeout events
• someone else’s exception? ➟ supervision
• location transparency ➟ seamless resilience
12

25. Elasticity
!
Responsive in the Face of Changing Load

26. Handle Load
14

27. Handle Load
14

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

30. … this has some interesting consequences!

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

33. Corollary
• Reactive needs to be applied all the way down
17

34. But what about us,
the developers?

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

40. Summary

41. The Four Reactive Traits
Reactive
Applications
23
http://reactivemanifesto.org/

42. All credit for this great slidedeck goes to Roland Kuhn (@rolandkuhn),
while any inaccuracy is mine.
©Typesafe 2014 – All Rights Reserved