Drivetribe’s Modern Take on CQRS with Apache Flink
data-artisans.com
data-artisans.com
In fact you don't even need that many moving pieces. Akka persistence does most of this out of the box: http://doc.akka.io/docs/akka/current/scala/persistence.html
Blue green deployments are a good addition here that many systems don't seem to be able to handle but the article doesn't really get into the details here.
I've done SOA, and n-tier DDD, and I'd love a chance to build something like this, but as an enterprise developer, I have to operate quite a bit behind the curve (13 years later, and 90% of my co-workers have never heard of Evans' book). Still, selling new approaches to management gets easier if you can point to exiting production systems like this, so, thanks for posting this wints.
[1]https://www.manning.com/books/functional-and-reactive-domain...
By logging all the interaction events and computing application state via a stream processor, you get all the benefit's of a log-centric architecture. Building different services as "views" over the history of interactions, forking the stream to test new applications, replaying data to test different recommender models, ramping up models on historic data and falling in with real-time data for continuous updates. That all becomes the same thing.
And for many use cases, you get better performance on less hardware because you have a simpler concurrency model.
PS: we do have lots of load
In my experience all these features sound nice on paper. But you quickly run into practical issues that are far easier when you know approximate information about the state.
E.g. Developing a model? you might just want a subset/batch data. Doing BI/Analytics? are you going to continuously tax your server to recompute? The argument about recommender systems is also honestly flimsy, having built and applied such systems to live traffic at very large scale (more than hundreds of millions of users). There is only a small advantage from being able to quickly reconfigure flows. In most cases you have a single baseline model which you compare against for a small fraction of the traffic. The real complexity/gains in recommender systems lie in choice of algorithm/hyper-parameters/features, not on continuous multi armed bandits with 1000 different models applied simultaneously while waiting an infinite amount of time to produce any statistically meaningful answer. In fact for a website like this one, recommender systems can only provide so much advantage.
There are actually several really good specialized use cases, e.g. Google secmon-tools uses a system like this one.
[1] https://web.stanford.edu/class/cs259d/lectures/Session11.pdf
I really do not understand how such a strong set of conclusions can be drawn out of so little information.
Interesting to see it used outside the .Net world.
I would question this, in fact suggest the complete opposite. Given that they say they're a team of Scala developers, I think there is definitely some selection bias going on -- in some subset of the wider population of developers that might be the case, but certainly not globally.