Michael Nash presented "Easy Scalability with Akka" at Scala Days 2015 in San Francisco & Amsterdam. Learn more on our blog and watch the video: http://bit.ly/1KpX9Z6 Every enterprise developer these days needs to be an expert in building REST API systems to enable mobile applications, SOA architectures and single page javascript web apps. The challenge is that most REST API backends can’t quickly scale to the numbers of requests needed in a modern enterprise. In this talk, we will introduce enterprise developers to Akka in an engaging and simple way and give them the confidence that they could quickly and easily build an enterprise web service that scales in their own workplace. This live coding session will showcase Akka’s power by taking an existing REST API and improving its throughput drastically by introducing a distributed actor system. Starting from a simple RESTful application exposing read and write operations, we’ll introduce a series of Akka features and patterns, scaling the performance and reliability of the system progressively. We will introduce the Actor pattern, and show how Akka brings this pattern easily and simply to the JVM. A simple actor system will separate concerns and serve as the basis of the exercise. Clustering will allow the system to grow and shrink dynamically, across one or more machines, with messages being passed transparently between nodes as needed. CQRS (Command-Query Response Separation) will decouple writes from reads and introduce non-blocking message handling, and Akka Persistence will make nodes tolerant to failure and avoid data loss. We’ll show how simple decoupling via message-passing of the system components allows you to scale each part of your service to match changing load. If you need more write performance, you can increase the number of nodes handling writes. Need more REST-API capability, increase the nodes binding to HTTP. Each element is independently elastic for full tuneability. Throughout the process, we’ll use Gatling to gauge our results in the form of handled requests per second. Watch our application go from Fast to Enterprise-Level Web Scale in 45 minutes or less, with very little code.

1. Easy Scalability with Akka
Distribute your domain

2. Who?
● BoldRadius Solutions
○ boldradius.com
○ Typesafe Partner
○ Scala, Akka and Play specialists
○ Ottawa, Saskatoon, San Francisco, Boston, Chicago, Montreal, New
York, Toronto
● Michael Nash, VP Capabilities
○ @MichaelPNash
○ michael.nash@boldradius.com

3. What?
What will I know in the next 45 minutes?
● Distributed Domain-Driven Design
○ What is it, and how does it apply to project?
○ What is CQRS and ES, and how to they relate?
● Akka
○ How to do DDDD and CQRS/ES with Akka
○ What is different in a DDDD Akka project, and why?
○ How does this kind of project scaled compared to a
“normal” project, even with Akka?

4. Scalability
● Scalability is not performance
○ Performance increasing reduces response time
○ Scalability increasing improves capacity in relation to
added resources
● Scalability can be...
○ Vertical (Scaling “up”): Bigger box (or boxes)
○ Horizontal (Scaling “out”): More boxes

5. ● The Actor model for the JVM
○ A share-nothing distributed message-
driven compute model
○ Scala and Java APIs
● Like Erlang/Elixir processes, only better
○ Distributed by design, local is an optimization

6. CQRS and ES
● Command Query Responsibility Segregation
○ Separate the read and write paths of the problem
● Event-Sourcing
○ State is built from a journal of events
● One doesn’t need the other, but they can be
combined very effectively

7. Event Sourcing

8. CQRS

9. Domain
● Your application’s domain is the part that
relates to the problem
● The rest of your application is infrastructure,
basically
● If you have a Payroll app, then Employees,
Benefits, Pay Stubs are in your domain

10. DDDD
● Domain-Driven Design (DDD) is not only for
Object-Oriented Systems
● Object-Oriented and Functional are not an
either-or choice, or at odds with each other
● Distributed Domain Driven Design is a
natural fit with the actor model

11. Traditional Domain Instances

12. Non-Distributed Domain
● Basic CRUD (Create, Read, Update, Delete)
● Writes and reads to same database
○ Always consistent
● Scaled via multiple identical replicas
○ and load balancing on HTTP
● Bottlenecks on contention
○ reads and writes interfere with each other

13. When we scale the traditional model…
● We add multiple servers
○ so there’s more than one copy of each domain
instance (potentially)
● Each must read state every time
○ from the shared resource (the database)
● Each must write (fully) to the same shared
resource to avoid conflict
● Scalability is limited

15. With Akka and DDDD
● Wouldn’t it be great if you could just keep
your domain instances in memory?
● But how to recover from its volatile nature:
an event journal!

17. But I have too many instances!
● Only active domain instances are in memory
● Instances activate and passivate as needed

18. Activation and Passivation

19. Ingredients
● Akka - Scala API
○ with Clustering and Persistence modules
● Cassandra
○ And the DataStax driver
● Typesafe Activator
○ For our template

20. What’s Different?
● Domain object instances are transient, and
memory-resident when in use
● Reads and writes don’t contend for
resources
● Cluster can be grown until domain instances
per node = 1

21. What do you get?
● Scalability
○ Add nodes to handle higher load on the fly
● Failover
○ No single point of failure or contention
○ Instances can be created anywhere as needed
● Simplicity
○ Build your app without having to worry about scalability
later

22. Consider your own domain
● Consider writes independently from reads
○ Are they really the same even now?
● Deployment structure is critical to get all
benefits safely

23. Example Applications
Online Auctions: Two implementations
● Users place bids for online auctions
● Most code shared
● Identical APIs
● Identical deploy structure, same machines,
same number of nodes
● One CRUD, One CQRS/DDDD

24. CRUD Actor
● Uses Akka
● Receives request
● Writes to datastore directly

25. CRUD Actor

26. CQRS/DDDD Actor
● In-memory state
● Recovers state from journal on startup
● Uses become to change states
● Passivates on timeout

30. Test Setup
3 Cassandra Nodes (Clustered)
3 Akka processing Nodes (Clustered)
1 Front-end (Part of the Akka cluster)
All Small AWS Instances
100 simultaneous users
100 auctions
Two minutes of bidding

31. Simulation

32. Response Time Distribution
CRUD CQRS
Scale is different!

33. Response Time Percentiles: CRUD

34. Response Time Percentiles: CQRS
Note that the scale is different!

35. Requests per Second: CRUD

36. Requests per Second: CQRS
Scale is different!

37. Total Requests/Responses in 2 mins
CRUD: 75,991
CQRS: 199,357

38. Adding more nodes...
● CRUD version
○ Contention increases
○ Diminishing benefit to adding more nodes
○ Tuning doesn’t help much
● CQRS version
○ No contention
○ Near-linear benefit until number of nodes = number
of auctions
○ Tuning is very important (type of nodes too…)

40. Activator Template
https://github.com/boldradius/akka-dddd-template
Add your own domain!

41. Q & A
michael.nash@boldradius.com

42. Further Reading