One bloke commented on a prior blog post that he wanted us to write more about our challenges at Nordnet IT. Well, in general we probably face the same challenges as any other customer centric, web based company. Our main focus is to maintain a robust and reliable platform that allows our customers to do their thing, and in addition produce new cool stuff at as high a pace as possible (without violating the reliability!)
Being a bank, and offering financial instruments trading as one of our main services, offers some extra dimensions of challenges though. I will expand on two of these core challenges in this and my next blog posts. First out: speed.
Speed and reliability
As a quite large player on the online banking scene in the Nordics (we have just about half a million customers at the moment), one operative challenge is to offer the same level of service regardless the climate on the stock exchanges where we operate. A long, quite silent period where we do about 50k trades/day, may in seconds burst into a volatile inferno where the amount of logged in customers is suddenly multiplied by X and the frequency of market information updates, orders and trades sky rockets. BAM! Our ambition is to provide constant latency and operability of our stuff, meanwhile ensuring 100% data consistency – no matter the circumstances. Our way to tackle this is a combo of (hopefully!) smart infrastructural architecture and software development principles where performance considerations are top of mind of all our hackers (ehrm, colleagues).
In other words we have to, on one hand, make sure we can handle a sudden exponential increase of user requests whilst still maintaining the same performance for each user, regardless of amounts of data transmitted. In the same peak moment, every user post request (such as sending an order to an exchange) has to stay within the same time boundaries as during calm periods. Both throughput and mass-distribution measures have to be constant and predictable.
- Modularity. We need to stay in control of what happens in various situations. Someone left the comment “Decoupling is the word of god” on Tommi’s screw-up blog post, and it’s worth stating again. Having a clear view of performance measures of each component in the stack is key in order to quickly be able to discover bottlenecks and prevent disasters. We try to maintain a plug in/plug out strategy to be able to do this. OK, I admit that this is a bit of a challenge in our darkest legacy pits of the system, but hey – what’s wrong with high ambitions?
- Enterprise. The further up the tech stack we move, the less is our usage of large enterprise stuff. To stay in control of your performance (where it really matters) requires that you are in full control of what happens and that you’re able to react and repair within seconds. Of course, in our bottom infrastructure layer we run well proven, highly commercialized systems for storage, virtualization, networking and such. The closer we get to the end user though, the less willing we are to buy some “you don’t have to worry about anything – this kick arse platform takes care of all your needs” – kind of monster. There is a vast number of various enterprise solutions on the application catering side, and they most probably work like a charm within the stated boundary conditions. But when the shit is heading towards the fan, they don’t. Evil tongues might whisper “bollocks, they say so just because they wanna do all the fun stuff themselves”. And well, of course it’s a fun challenge following this path as well, as it demands quite a lot of our innovative capabilities and guts.
- Home brew & open source. Our more home cooked alternatives on the application level contains quite a few colors of the palette, each considered (by us) to be the best tool for that particular job. A couple of examples embrace Erlang for mass distribution of market- and instrument data, open source components such as LMAX Disruptor and Java Chronicle for inter thread messaging and state handling in our trading services where latency as low as possible is crucial. Moving up the stack towards the client side, some really cool innovations are currently taking place in development of our next gen mobile apps (see a previous blog post on this topic by tech lead Andreas).
Well, that’s it for now. I will soon get back to touch on a few other specific dimensions to a considerably “techy” bank.