Hi AKKA experts!

We are building an OLTP gateway, were this gateway has the following 
(partly) requirements:

High-throughput and low latency, no single point of failure, and fully 
scalable solution with initial capability for 500 tps per instance and 
scalable to 5000 tps.

(but of courseJ)

The gateway will also have to integrate with third party services (like - 
acquiring banks, alternative payment methods and other implementations).

We have many system zones (and modules within) so for the sake of clarity I 
will mention two:

Core Gateway zone – encapsulates many modules consisting together the OLTP 
engine.

And Backend Integration zone - for these third party services 
implementations.

Our system zones separation considered the ability to scale module 
independently in a clustered environment when the module overloads.

 

We plan on using AKKA and Camel platforms as the basis for the gateway 
architecture

We chose these platforms for their well known advanced features.

We are new to AKKA and Camel platforms so we did a lot of research and 
learning over the web and we feel very confident with its capabilities.

 

So right now our main concern is with AKKA's routing and load balancing 
messages/requests/work between our modules and system zones.

We try to find out if using a regular NLB between our system zones will be 
a better choice to go with.

We try to mesure our decision according to the following parameters and 
order:

1.    Performance

2.    Known and successive implementation

3.    Statistics

4.    Fault-tolerant

5.    Routing strategies

6.    Configuration

7.    Debuging on (near) real time

We belive that the sections 4-6 in the above list can easily satisfied by 
AKKA and we wonder about the first three and section 7…

We have researched over the web for information about AKKA's routing and 
load balancing and came out with many good articles.

here are some: prochera.com 
<http://prochera.com/blog/2014/07/15/building-a-scalable-and-highly-available-reactive-applications-with-akka-load-balancing-revisited/>
 | typesafe company casestudies 
<http://www.typesafe.com/company/casestudies> | doc.akka remoting 
<http://doc.akka.io/docs/akka/snapshot/java/remoting.html> | doc.akka 
adaptive-load-balancing 
<http://doc.akka.io/docs/akka/snapshot/scala/cluster-usage.html#adaptive-load-balancing>
 | stackoverflow.com 
<http://stackoverflow.com/questions/4493001/good-use-case-for-akka>

But we did not found much of information that will help us to decide which 
is the better aproch (AKKA's routing and load balancing VS regular NLB)

So finally here are banch of questions concerning our dilemma:

1.    Can you provide some statistics on AKKA's routing and load balancing 
performance in distributed systems?

2.    Can you provide comparison between AKKA's routing and load balancing 
VS regular NLB?

3.    Can you provide known and successive implementation in the market?

4.    Is there known problems/cons using AKKA's routing and load balancing?

5.    We wonder on a solution that implements AKKA yet let external load 
balancing do the inter-machine communications - which can be replaced by 
all AKKA mechanism at a later phase.
Can you think of one?

6.    Can AKKA perform sticky based load balancing onto multiple backend 
servers?

7.    Is it easy to debug / log trace on (near) real time the AKKA's 
routing and load balancing?

 

Would really appreciate some feedbacks.
Tzvika

-- 
>>>>>>>>>>      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