Thoughts on Reactive Systems

[jducoeur]

This one's just for the programmers/architects, and mainly for the experienced ones: Things I Wish I Knew When I Started Building Reactive Systems.

The more you're used to building traditional Tomcat-plus-RDBMS applications, the weirder you're going to find this, but it's well worth reading and absorbing. It describes a few of the assumptions underlying modern, scalable, so-called "reactive" architectures, each of which gores one of the traditional sacred cows you're probably used to. What it all boils down to is that it's entirely possible to build seriously efficient, seriously scalable online services -- you just have to change a lot of well-worn habits.

(Querki is built around all of this stuff, except that I still have some blocking I/O in the MySQL code; replacing that with a better approach such as Slick is becoming an increasingly high priority.)

And this reminds me: among other things, it links to the paper Life Beyond Distributed Transactions. If you're playing at the Senior Software Engineer or above level, this is one of the most important papers of recent years, and you should read it if you haven't already done so. It was the paper that finally demonstrated that the emperor has no clothes: that the traditional transaction-oriented model of data processing doesn't scale well, and that you need better approaches if you're going to compete in the modern world.

For all that it calls itself "An Apostate's Opinion", it has become something like the new gospel. It has inspired enormous ferment and evolution over the past decade, and led to radically new architectures (such as the event-sourced approach that Querki is now mostly built on). If you are doing architecture for systems that are intended to scale, you need to understand this stuff in order to understand how the industry is evolving...