Welcome to the third edition of our Technical Development Progress Report where we’ll dive deeper into the Performance Engineering used to power the upcoming Klever Exchange.
Another super busy week, with so many challengers to overcome and together, supporting one another, we did it!
The team kept our focus, hard work and passion. That’s why I can’t feel anything but excitement!
Performance Engineering
This week let’s talk about our performance engineering used by the Klever tech team.
These are the processes behind the scenes that enable us to build the Klever Exchange, a High Performance Exchange, with our overarching goal to be a cheaper exchange, making possible to process huge amount of trades with small amounts and low fees.
Our Performance Engineering Process is part of our #devsecops squad with cross field specialists who joined the #KleverEx squad to apply their expertise.
This process ensures high performance and resilience in our services, from the development phases to production environment. It is a cycled operation, that is loaded in every new release of the #KleverEx product.
The goal is to find and remove any possible bottlenecks that could limit the throughput of the exchange and its service to our users.
We see how the service will behave with an extreme and heavy load, and then analyze software architectural improvements, always seeking a more scalable and high performance solution with the lowest possible cost.
Before we go to the results, let’s talk a little bit about the software architecture used to power the #KleverEx. It is based on the Event Driven Microservice Architecture build on top of the Kubernetes (K8s) and Golang.
This solution guarantees us to have:
Loosely Coupled Structure – Event creators, such as when you create an order or your order is filled, and event consumers, like the UI informing you about the state of your orders, loosely coupled with event bus help, which assists them to the couple and decouple into different platforms (Android or IOS) in response to various events. It also enables us to have different developers develop different event processors with greater speed. And use these components and also reuse by many different platforms.
Real-time Analytics – Optimized event-driven architecture for real-time analytics. It has a much higher capacity to find, analyze, and then respond to patterns in time before critical events happen, thereby avoiding their occurrence in production. Using complex event processing to achieve real-time analytics.
Versatility – A system that follows event-driven architecture facilitates greater responsiveness because event-driven systems are, by design, normalized to unpredictable, nonlinear, and asynchronous environments. These systems are highly adaptable in different circumstances.
In simple words, this software architecture means:
Less effort to build the #KleverEx for the 3 planned platforms: Android, IOS and Web;
A real time UI, for the 3 planned platforms;
And an over more resilient solution.
Kubernetes, originally developed by Google, allow us to build and re-build environments as we wish, and as many we need. Using Infrastructure as code we can scale environments and services to fit our needs, only at the limit of our budget with cloud providers.
So, after any release we run the load test into the staging environment, and validate whether the performance is better than the last version. If it is worse, we simply block that code release and ask to the team to fix the bottlenecks found on it.
As an example, in one of our measurement of the services, fired over a release candidate code we just hit the performance limit at 114 Virtual Users (bots or robots that do non-stop requests without thinking time).
So, the team analyzes the performance data, identifies bottlenecks and software architecture limitations, and optimizes based on those results.
So, on the next day after changes in code, improving the usage of cache in the service level, and many others improvements we repeated the test on the fixed version and reach out the first level of the performance needed, that’s 250 Virtual Users (bots or robots that do non-stop requests without thinking time).
We ran the test until it reaches 550 Virtual Users and the service keeps the good performance above, so we green lighted this version.
Using these methods, we keep improving our services to bring to our community a high performance and resiliently scaling Klever Exchange experience.
Now, let’s see the overall progress in other squads this past week:
Klever Exchange
Klever Wallet
Klever Hard Wallet
Klever Workspace
I hope you enjoyed hearing more about the Performance Engineering of #KleverEx this week and the general technical progress made by our team. I can’t wait to see you next week!
Sincerely,
Bruno Campos
CTO at Klever
