Here’s a short post with linked slides and the recording of our third Reactive Systems Hamburg Meetup. We were very pleased to have Dr. Roland Kuhn as guest, presenting some highlights from his new book Reactive Design Patterns that’s currently in MEAP and should be finished in 3 to 4 months (I can highly recommend it!).

Because I already spent a few words about our Reactive Systems Hamburg Meetup in the last meetup related post (Event Sourcing/CQRS with Akka Persistence and Eventuate) I won’t reiterate that here.

Now let me give you an overview over Rolands very interesting talk.

Intro: Reactive Traits

At first, Roland introduced this “Reactive” thing with the two main motivating factors Elasticity and Resilience from the Reactive Manifesto.

• Elasticity: because we need to handle varying load, we need to write our applications so that it can be split up and be distributed across several machines
• Resilience: because 1) most applications must provide high availability and 2) things will go wrong, we must not put all eggs into one basket. Again, our application must be distributed.

Based on the assumption that we want Elasticity and Resilience, he showed what we get from this:

• Responsiveness: we want to have systems that respond in a timely manner, under varying load and in the case of failures
• Decoupling: we want compartmentalization (required for Resilience), which forces us to have clear system boundaries and loose coupling
• Maintainability & Flexibility: is a result we get from clear boundaries and loose coupling
• Asynchronous Messaging: is required to achieve the properties mentioned before

Here’s the intoductions’ summary slide:

Reactive Design Patterns

After core components of Reactive were clarified, Roland continued to talk about Reactive Design Patterns: at first architecture patterns, followed by implementation patterns.

As architecture patterns Roland selected the Simple Component Pattern (a.k.a. the Single Responsibility Principle) and the Let-It-Crash Pattern. In the book both are part of chapter 12, Fault Tolerance and Recovery Patterns.

• Simple Component Pattern: A component shall do only one thing, but do it in full
• Let-It-Crash Pattern: Prefer a full component restart to complex internal failure handling

As implementation patterns Roland chose the Circuit Breaker Pattern (in the book also part of Fault Tolerance and Recovery Patterns), followed by Multiple-Master Replication Patterns (ch. 13, Replication Patterns) and finally the Saga Pattern (ch. 15, Message Flow Patterns).

• Circuit Breaker Pattern: Protect services by breaking the connection during failure periods
• Multiple-Master Replication Patterns: Keep multiple distributed copies, accept updates everywhere, disseminate updates among replicas. For multi-master replication there’s no perfect solution, it’s always a trade-off between consistency and availability
• Saga Pattern: Divide long-lived distributed transactions into quick local ones with compensating actions for recovery

Conclusion

Roland finished his talk with the conclusion that

• reactive systems are distributed
• this requires new (old) architecture patterns
• … helped by new (old) code patterns & abstractions
• none of this is dead easy: thinking is required!

Thanks a lot to Roland and to all attendees, again this was an awesome Reactive Systems Hamburg meetup!

Now have fun checking out Rolands slides and enjoy the video!