Design motivation question for distributed command bus

Imported from Google Groups
#1

With respect to single jvm axon without distributed bus implementation…

Wouldn’t horizontal scale be acheived by the following

  • embedd axon as part of webapp jvm and scale horizontally via web app load balancing
  • multinode mongo in background for all persistance, you could also cluster mysql or postgresql

Thats it…I must be missing something??

In what topology would distributed bus be helpful, e.g. if jvm is under heavy load in traditional world wouldn’t web app load balancer intelligently route to the next horizontal webapp jvm?

Thoughts and design opinions…

Thanks and Cheers.

#2

Hi,

the architecture you propose will give you a lot of concurrency problems when users act on the same aggregates. A load balancer will distribute load based on either randomness or session identifier. So two users acting on the same data are likely to be routed to different machines.

Let’s assume user Ua and Ub are acting on an aggregate on machines Ma and Mb, respectively.
Ua and Ub simultaneously load the aggregate (let’s say version 1) on Ma and Mb. They both change the aggregate.

Now, the first user to save the aggregate will succeed. The second will fail, because it has caused state changes on an aggregate that was concurrently modified. It’s not safe to assume that can be safely done.

The distributed commandbus ensures that commands for the same aggregate are always routed to the same machine. That allows for caching to be enabled on those machines, increasing performance.

That’s why.

Cheers,

Allard

#3

Thanks Allard… helps clear things up in the sequencing of same user data concurrency, however in typical single user type apps where only one user is messing with their aggregates, it may work, but can see corruption and locking problem scenarios in async operations form the same user hitting parallelly to the server with some chance of overlapping async threads and locking sequencing would be key to integrity of the data.

Eager to want to test a two node config to see Axon scale multi-node end to end. As for now one jvm is what seems to be working ok.

What would be very helpful is to showcase a thorough 2 node infra with the preferred integration tools e.g. Mongo/mysql cluster, Apache Tomcat cluster, Quartz on mongo/mysql cluster, Rabbit mq config for 2 node etc and a simple one click through for 2 parallel tracks end to end into backbone from two webservers–>commandbus—>persitance. Also, this could be emulated on a single machine with ip/port configs and virtual processes for simplicity.

That would really help sort out all the what if/why type questions and also allow rapid adoption of the platform. Again, this could be the smallest of use case e.g. current trader app or something even simpler in this configuration.

Looking forward to playing with and testing multinode infra. Any idea when something could be available in beta. Understand that you were thinking summer for release from a previous post.

Thanks and Cheers…

#4

Hi,

we will be using the current trader application to showcase the scalability features. It has the most common use cases, such as complex transactions, set validation (unique usernames), etc. The idea is that the application can be scaled over multiple nodes. And as you mentioned, it can be done on a single machine.

I am going to try to get the first milestone release out before summer. There is a lot left to do, but I’m working hard on it.

Cheers,

Allard