Hey, I'm not an Akka expert, in fact I just read the docs and did some very minor POC with it, but, I guess I can answer some of your questions at some level,
Q1) Akka is naturally async, this is one of the core principles of Akka, you pass async messages between actors and they can reply to back / spawn new child actors, etc, but everything is async. Q 2) You can use Akka Logging for logs (that's what I do) (http://doc.akka.io/docs/akka/snapshot/java/logging.html), regarding recovering from errors, You can definitely spawn (and should) new children actors to split the work whenever you want, I personally tries to minimize the job of each actor as much as possible and make a reuse of the work units, due to actor hierarchy, a supervisor always responsible of its subordinate work, and you have a choice how to recover when a subordinate actor fails (whether to resume / restart stop subordinate actor, escalate failure, etc.) This is explained here: http://doc.akka.io/docs/akka/2.3.8/general/supervision.html Q3) This is definitely achievable, you should read blog this for more info: http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/ Hope it helps. On Saturday, January 17, 2015 at 12:48:10 AM UTC+2, Ashesh Ambasta wrote: > > I had a quick question: I'm a lead developer at a small startup and we're > working on a solution that depends on the data in our core service to push > out periodic updates to other API's (like Facebook, Twitter, etc.) and we > want to build a microservices arch. We intend to keep the core service and > the data-push service across multiple instances. Is Akka going to be a good > choice for a problem like this? > > We've built our core API using Scala and the Play Framework and we're > happy with the outcomes. And while we were working on the core, we began to > look into Akka and it looked quite interesting, given the buzz it has > around the web and the success stories. > > We will, however, need some convincing about a service like the one I > mentioned. What we will definitely need from a system like this is; > > > - The system should process push requests concurrently: other requests > shouldn't be blocked if the remote API is taking too long to respond. > - Errors should be logged and reported, and failed requests should be > queued back. > - We're talking about potentially hundreds of requests per minute in > the beginning, we've heard good things about Akka's performance, but we're > yet to come across a similar use case to be sufficiently convinced. > - It should be possible for the core service to communicate with a > remotely running Akka service. For example; the Core API runs on some > instance, and the Akka services run on some other instances. A push > request > is initiated in an action of the Core service – where a push request is > sent to Akka. The appropriate service for that API should pick that up and > send it to the target API and report back with a confirmation. > > I'm quite keen on diving into Akka for a project like this, but as I said > before, I'll need some convincing. > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.