+44 (0) 203 811 8344
In this article, Mike O’Hara, publisher of The Trading Mesh – in conversation with Jonas Bonér, Greg Young, Martin Thompson and Jan Macháček – investigates the core principles behind the recently published The Reactive Manifesto, and its relevance to system design in today’s Financial Markets.
Anyone who has been closely involved in designing and building high-performance trading applications within the last ten years or so, will no doubt be familiar with the principles of asynchronous, concurrent, distributed programming, and the need for incorporating scalability and fault tolerance into their designs. Such principles form the basis of reactive applications and reactive frameworks, and successful trading systems have always needed to follow this approach in order to be able to rapidly react to events, react to load, react to errors or failures, and react to users.
It is these four principles of system design – event-driven processing, scalability, resilience and responsiveness – that are at the core of The Reactive Manifesto, a document authored last year by an eminent group of technologists, including Jonas Bonér, Erik Meijer, Martin Odersky, Greg Young, Martin Thompson, Roland Kuhn, James Ward and Guillaume Bort.
The principles outlined in The Reactive Manifesto are of course not new. They have been used in a number of industries dealing with low latency, high throughput applications for some time. In fact, the Erlang programming language developed by Ericsson in the mid-1980’s was specifically designed to be event-driven, scalable and resilient.
“ The important point is that you can build reactive applications in any language, using almost any tool. It’s more about adhering to the core principles and thinking about application design and application architecture.”
Jonas Bonér, CTO of Typesafe
So why is there a need for a new manifesto to describe these traits? Jonas Bonér, CTO of Typesafe, inventor of the Akka framework and the driving force behind the Reactive Manifesto, explains.
“Even though these are old principles, the need for the manifesto is there”, he says.
“We live in a world now that requires this approach for almost any application, particularly if it is to be put up on the Internet; if it needs to drive mobile devices; if it is to make the most of multiple processing cores; or if it needs to fit cloud computing infrastructures. The need to go reactive is even greater when the application needs to provide sub-second (or even sub-millisecond!) response times.
“But there is no single tool or single language that will do all of the jobs”, continues Bonér.
“At least not in a moderately complex or advanced application. As a result, a lot of sub communities have built up around certain tools and languages and they’ve developed their own strategies for dealing with specific challenges. We wanted to look at the whole landscape across all of these communities to see how people are really solving these problems, to try to distill the core principles behind all of these languages, features, tools and frameworks.That’s how we ended up with these four key traits of The Reactive Manifesto: event-driven, scalable, responsive and resilient. And the important point is that you can build reactive applications in any language, using almost any tool. It’s more about adhering to the core principles and thinking about application design and application architecture”, says Bonér.
The first version of The Reactive Manifesto was published in June 2013. Since then it has undergone various iterations and is now starting to be embraced particularly warmly by the .NET, Java, JavaScript, Haskell and Erlang communities. The Reactive Manifesto providesa common vocabulary to describe the widely differing terminology that each language and runtime brings.
But how does it apply specifically to the financial markets? Independent consultant and serial entrepreneur Greg Young, who coined the term “CQRS” (Command Query Responsibility Segregation), and has a background in designing and building gambling and algorithmic trading systems based around reactive principles, throws some light on this.
“I’d be willing to bet that in any financial institution the accounting and the back office systems are not written in a reactive style, even though they should be.”
Greg Young
“What’s interesting to me about The Reactive Manifesto in the finance space is that most people who’ve been building trading applications would look at it and see it as being self-apparent, because they’ve been doing things this way for decades”, says Young.
“Taking The Reactive Manifesto and bringing it to algorithmic traders is preaching to the converted. But there are a lot of other systems in financial organisations that absolutely need to realise what we’re talking about when we talk about reactive. I’d be willing to bet that in any financial institution the accounting and the back office systems are not written in a reactive style, even though they should be”.
How can more mainstream applications in banks and finance houses benefit from the reactive approach?
“In any financial organisation, everything can be seen as a series of facts that happen at points in time. Regardless of whether it’s a trade occurring, a position being cleared or a settlement failing, all of those things are facts that are happening at points in time. And they all fit very well into the reactive model”.
And in response to possible difficulties, Young adds:
“With back office settlements for example, you could have a bunch of events that sit in a batch-processed queue. And if you look at a large batch operation in the back office of a bank, adjusting that process for near real-time is inherently more complex than writing a stored procedure that gets run on a scheduler at midnight.
“But in order to completely re-design some of these applications, and to move from a synchronous approach to an asynchronous, parallelized-type design, you need what I would call higher-minded developers”, says Young.
“And then you will start finding all the same benefits of why people are building trading systems this way. How much cooler would it be if you could actually trigger operations in near real-time as opposed to having users running reports at the end of the day and looking for discrepancies? Particularly in areas like risk and compliance, especially counterparty risk”.
Jan Macháček, CTO of Cake Solutions, an enterprise software solutions provider that specialises in reactive application design, explains that it is not just the wholesale and investment banking sector that can benefit from The Reactive Manifesto approach, there are many advantages to be gained in retail banking too.
“Reactive applications play a significant role in retail banking, particularly in mobile”, he says.
“The customers expect information delivered to their mobiles quickly & reliably. Whenever a mobile banking or mobile payment system fails, the damage to the bank’s brand can be far-reaching. And so, the systems that drive these front-line applications have to follow the reactive principles.
“The pressure to adopt the reactive programming style grows even bigger when one considers the possibilities and challenges of new currencies and new patterns of customer expectations”, continues Macháček.
“ Understanding and applying The Reactive Manifesto to retail applications allows the banks to offer new and innovative services.”
Jan Macháček, CTO of Cake Solutions
“The underlining principle is again responsiveness & reliability for the consumers, which means these systems need to be scalable and event-driven.
“Understanding and applying The Reactive Manifesto to retail applications allows the banks to offer new and innovative services, particularly in the AML and KYC arenas. Identifying and knowing your customer needs to be seamless: no one wants to type passwords and memorable words on the go, and yet the banks need to be certain that the customer’s money is safe. One can think of these challenges as events—pieces of a puzzle—that must fit together perfectly; these events must be processed in a timely manner by a system that is resilient and that can scale up and down to cope with the demand”.
So what are the key challenges to wider adoption of The Reactive Manifesto principles across the financial industry?
High-performance & low-latency computing specialist Martin Thompson, who designed the Disruptor open-source concurrent programming framework and is another co-author of The Reactive Manifesto, shares his insight on this topic.
“There is an obsession in our industry with synchronous design, which fundamentally limits so much of what we do”, says Thompson.
“But getting people out of that is an interesting and very tricky challenge, because it becomes so instilled and indoctrinated in people. Synchronous designs tend to be quite quick to get the first iteration of something up, but then they don’t cope and they don’t scale beyond that point. For example, if you get error conditions, synchronous designs tend to get a lot messier in the code, and then the code gets more coupled, it gets more complex as you deal with error conditions and side effects. As you scale up the development cycle, things gets slower and slower, from both the delivery and the system performance perspective. Whereas with asynchronous system design, you start off with it being a bit harder because you’ve got a few more things to contend with initially, but once you’re over the initial curve, you get a nice decoupled design, you’ve got the ability to handle failure and the discipline that comes behind it. Once you’ve got the basic fundamental building blocks in place, your delivery cycles get faster and you can deal with failure and with performance issues better. But there’s a greater activation energy needed to begin with”, he says.
“It’s like many things. We seem to live in this instant gratification society, where people take the easy option to begin with, but it’s actually the harder option in the long term”.
Does that mean that the reactive approach applies to how you run your teams and manage your development projects as well as how you design your code? It certainly has interesting effects on it, according to Thompson. He refers to a theory known as Conway’s Law, developed by computer scientist Melvin Conway in the 1980’s, which states that any system takes on the shape of the organisation that built it.
“Whether you’re building systems in software, or building organisational systems to build that software, or building systems that interact with the business in some way, it’s all the same, you’ve got to look at the system holistically and work out how to make it more efficient and more effective in how it works”, he says.
“It’s interesting that the more mainstream development could benefit hugely from The Reactive Manifesto, but it’s almost not in their interest because they don’t have the extreme requirements that bring a lot of these issues to the surface, and they tend to employ developers who are driven by what looks good on their CV. And unfortunately as a result, with Conway’s law coming into effect, we get systems designed from CV-driven development”.
Bonér agrees with this analysis.
“With Conway’s Law, the application tends to take on the shape of the company’s organizational structure, so if you have a distributed team or a large team that’s split up, then you need to have really good protocols so that those components can talk to each other. And that’s also something that having truly reactive, event-driven applications enables”, says Bonér.
With over 4,000 signatories since it was published, The Reactive Manifesto is certainly building momentum and starting to gather a following. But where does it go from here?
“The Reactive Manifesto should be – and is – a living document”, says Bonér.
“We want it to evolve over time; we want people to contribute to it, and that’s why we have it on GitHub, where people can create pull requests. That’s already happening from other communities, like the Erlang people for example.
“The idea of having people sign the manifesto is to try to create a passionate community. By signing it and adding a ribbon to your website, you are showing that you actually take a stand, that you believe in this way of doing things and believe that this is the future, and that you seek change. The more people who are into it, the easier it is to create this movement. That’s how humans work, we want to gather around things, we want to feel that we have a higher purpose, and we like communities”, says Bonér.
“People ask if this is just the latest fad, and that’s a fair question, so we need to look at how we educate people on this, so they start to realise what is important and why.”
Martin Thompson, High-performance & low-latency computing specialist
From Martin Thompson’s perspective, The Reactive Manifesto is a starting point.
“I see this as a set of principles that starts a discussion about what’s important”, he says.
“People ask if this is just the latest fad, and that’s a fair question, so we need to look at how we educate people on this, so they start to realise what is important and why. I think this is going to be one of the challenges in describing something like The Reactive Manifesto, in that it has a lot of really important concepts in it and when you put them all together you can build very effective systems that are well-suited to the finance space.
“It’s interesting that the people who are very competent in financial technology, for example people who have built exchanges or trading systems dealing with high volume flow, they instinctively already get this because they’ve been through a lot of the battles. And the feedback I get from some of those people is that The Reactive Manifesto is a nice articulation of all of the important issues one faces when building those systems.
“But the subtlety of understanding as to why these things are important in a wider context is the next challenge”, concludes Thompson.
