How is Akka used in Play?
Solution 1:
In Play 2.0, Play delegated all requests to go through an actor. It heavily depended on Akka's future API and other parts.
In Play 2.1, with the move of Akka's future API into Scala 2.10, Play started depending less directly on Akka. It gets all it's execution contexts from Akka, and provides integration with Akka, but that's about the extent of it.
In Play 2.3, we're adding new features to aid Akka integration, particularly around WebSockets.
In Play 2.4, Play will be ported to the new akka-http (formerly known as spray), at which point, Play will be as built on Akka as you can get.
What are the consequences? Akka provides a paradigm for programming that makes concurrency simple to deal with. It also provides great abstractions for distributed programming - the hardest thing about distributed programming is dealing with failures (which happen all the time) appropriately. Most tools try to address this by trying to hide failures from you, but unfortunately hiding something doesn't make it go away, and actually really makes things harder because when you try to address specific types of failures, the fact that they are hidden away from you gets in your way. Akka pushes failures in your face, so that when you're coding, you are forced to think about how your application will respond to failures. Consequently you're forced to design/code your application in such a way that it is tolerant to failures. It also gives you the tools to deal with them in a hierarchical fashion, allowing you to specify at what level you want to handle what type of failure, and how the failure should be responded to (die, retry up to n times, etc).
So how does this help Play? The better question is how does it help a Play user? Akka helps me to implement Play itself, but it's possible to implement it without Akka (in fact Netty does most of the heavy lifting now, that will change in Play 2.4). The important thing is that Play seamlessly integrates with Akka, making it easy to handle HTTP requests with actors, handle failures etc, and this helps Play users because it allows them to design their application in such a way that it is scalable and resilient.
UPDATE: The above was written 3 years ago, a lot has changed since then. Play 2.4 did provide experimental support for akka-http, but Play still by default uses Netty.
In Play 2.5, we deprecated the iteratees API and switched to Akka streams. This meant that now all asynchronous IO was going through Akka streams. Soon (not sure if that will be Play 2.6 or later), Play will flick the switch to make akka-http the default backing implementation of the server (though not yet the WS client).
UPDATE 2: Play 2.6 now makes akka-http the default backend implementation of it's HTTP server (Netty is still available as an option).