visit
Is there anything more annoying than a slow performance of your go-to application? At the time when most people are used to apps that respond quickly, work efficiently, and are updated regularly, market-oriented companies find themselves in a position where they must keep up with the pace or become extinct.
For , as well as for many other fintech platforms, a brand new approach to IT development based on microservices has become the key to scalability and speed. What exactly is microservices architecture and why it’s giving early adopters an edge over everyone else? Let’s turn our app inside out and see what’s beyond its interface.
Huge micro solutions
Microservices is one of the hottest buzzwords in the tech world right now. Netflix, eBay, Amazon, Twitter, PayPal, Uber, and many other large-scale websites have all evolved from monolithic to microservices architecture. And as is often the case, smaller players have been quick to follow the example — 8 companies out of 10 now say they are going to transmit to the new model in the nearest feature, according to Dzone. So what are microservices?
Basically, they are independent modules that can run on their own and may be created using different programming languages. Each of these modules is responsible for a discrete task and can communicate with other modules to solve a larger complex business problem. In addition, they are easier to understand and maintain and are much faster to develop, which means that new value for the customers can be delivered as quickly as possible.
“As opposed to the pattern we use, the monolithic structure is built as a single, autonomous unit. Whenever a slight modification is needed, it often comes with rebuilding and deploying an entirely new version of the app” — says CTO of Crypterium, Pavel Ivanov. “It all results in endless delays. And when it comes to updating the app, the system may go even down for about 10–15 minutes” — he adds.
Yet, for established enterprises like state banks, moving on to microservices might be too adventurous — it’s really not as simple as taking your core system and shoving it into modules. To truly adopt microservice architecture and remain relevant, companies will have to change not only what they’re deploying, but also the people who are doing the deployment.
What happens on the ‘server-side’ stays on the ‘server-side’
If you’ve been following along the past few months of our progress, you might have seen a serious shift in gears: we are now launching new features almost every week. But what you couldn’t see is what’s been going on on the “server-side” of our app.
The process of releasing any product always comes along with fixing bugs. The goal is to make sure the whole process goes smoothly. To understand this magic of product development, let’s get a bit deeper into the details. Here’s a simplified model of the Crypterium app system.
As you can see, user’s request goes through the load balancer that allocates traffic and matches the request with the needed service. These services are being run inside containers — you can think of them as the packaging of software, including everything it needs to operate: code, system tools, system runtime, and settings. What makes containers a perfect match for such a dynamic and constantly updating application as ours is their plug-and-play nature — they can be mixed, reassigned to new tasks or removed from the system without affecting it as a whole. This means that when a change is introduced to one service it can be rolled out across a minimal subset of the overall cluster of containers: just those powering that feature.
Dynamic infrastructure in action
Now to adding new features. Say, we’re going to update our app with something significant like “crypto bank transfers” feature. Before making it public, we test it with real traffic.
First, a container powering the future function comes out, and then the balancer allocates the working load taking that container into account. If it can’t cope with the incoming traffic or works incorrectly, the system reverts it back automatically. In case it is running smoothly, the balancer gradually replaces containers that hold old functions with the upgraded containers. After every one of them is replaced, the new feature goes live.
_“The irony is that the updates happen right in front of us, but we can’t see them from a user perspective. And this is actually how it should be, right? Thanks to the architecture we’ve managed to create, new features can be added without introducing the risk of destabilizing existing ones” — says Sergey Positurin co-_CTO, systems architect at Crypterium.
Last but not least, the approach gives us more control over resource allocation and scaling. If there are not a lot of user requests, the system keeps unneeded containers off. In case there is a spike in traffic, it activates extra resources ensuring the app workflow goes uninterrupted. What we are saying is that Crypterium is ready for big releases and a high load that comes with it. And some of those big releases are just around the corner, by the way. In a couple of months, Crypterium is launching a long-awaited feature that will make it possible to pay with crypto at any NFC terminal, or via scanning QR codes.
*You can also read an article on how Crypterium survived a DDoS attack to learn more about our cyber security system.
About Crypterium
Crypterium is building a mobile app that will turn cryptocurrencies into money that you can spend with the same ease as cash.
Shop around the world and pay with your coins and tokens at any NFC terminal, or via scanning the QR codes. Make purchases in online stores, pay your bills, or just send money across borders in seconds reliably and for a fraction of a penny.
Learn more at and join the discussions in our Telegram Chat.