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.

Reply via email to