0%
#Setting

Engineering@Bitpanda: Why we at Bitpanda Pro love Vert.x

Jan 27, 2021 6 min read
News Article Banner Image

Back in 2018, when we set out to build the next-generation JVM stack to power our growing business, we set out some goals:

  1. Start small and scale to ride the next Bitcoin bull run

  2. Service customers faster than in the blink of an eye under varying loads

  3. Service customers 24 hours a week, 365 days a year

  4. Stay transparent: when a service is under-performing, clients learn about this, and can immediately react

Then, we quickly learned the fastest human eye-blinkers's performance is roughly 200 milliseconds. Also, apparently there are many fast eye-blinkers who want to jump on the Bitcoin band wagon. As the business goals and the first set of requirements became known, a more refined set of software-engineering goals was identified:

Stick to domain-driven design, identify natural context boundaries

We were not sold on orchestrating tens, possibly hundreds of microservices. Instead, we wanted to start with just one service and add more if the need arose.

Design software with resilience in mind

Each service implementation should have well-understood and testable unhappy path handling. Whenever this path is encountered and the system cannot self-heal, all errors are transparently propagated to a supervisory entity and the faulty instance is removed from the operation. Finally, if there are faults in the system, they don't propagate to other context boundaries and bring our whole operation to a halt.

Avoid heavy frameworks which come with tons of dependencies

Each dependency comes with some hidden cost. One is its potential exposure to security vulnerability. The other is losing control altogether, which means performance-tuning and just keeping our application maintainable, scalable and predictable is a much more difficult job.

H1: Multi-Reactor For The Masses

Enter the Vert.X and its 650 kB of asynchronous, reactive Java framework goodness.

At the core of Vert.x is the principle event-handling. Traditionally, Java applications scaled by encapsulating work-loads on Threads. While in modern multi-core systems, threads are cheap and operating systems are built to support enormous amounts of concurrent workloads, in Java, it is still quite complex to reign in orchestration of threads.

This has partly to do with Javal's memory model (chapter 17.4) when threads have to access shared memory - heap space. Get this wrong and you are in for some pretty frustrating hours of debugging out-of-memory, dead-locks, live-locks and the likes of Java concurrency.

Now imagine we set a number of available threads in the system to a fixed number up-front. We don't create any new threads while running the application and design workload execution to take place on any of these threads. Furthermore, the application instructs the execution layer on what to do by emitting events and by registering handlers ( who does it) which execute in a so-called event loop. When the processing of one event is finished, the next event-handler is called to occupy the underlying thread.

In summary, the life cycle of threads and the entire cost of concurrency management is completely solved by the framework.

Multi-Reactor Pattern

At this point you might think, this is all well and good, but how does it relate to your goals that you set out to achieve? Well, imagine the service you've been commissioned to build is a HTTP server. In case of Vert.X you can seamlessly hook your event handlers to Netty's ChannelHandler (another multi-reactor) and your final setup could look like this:

Multi-Reactor HTTP Server

Notice the time axis at the bottom where every slice represents concurrent processing of user requests using registered event handlers. Some requests may be very cheap to complete - fetching current account balance, while others - processing a new client order - may take longer. This means that while one thread is occupied by creating a new order to buy Bitcoin, the other registered event handlers may complete processing requests to deposit or withdraw funds on the other available thread.

Verticles As Context Holders

Verticles are the entry point to Ver.X multi-reactor. Each Verticle is spawned with its own Context which is not visible to other verticles. This forces developers to organise code in a perfect share-nothing encapsulation. Moreover, each context allows for perfect testability of the business logic. Integration to database or message-oriented-middleware which resides in other contexts can be mocked and eventually tested separately.

A good practice for writing verticles is to register an exception handler which nicely aides our goal of resilience by design.

@Override public void start(Promise start) { //do this before anything else context.exceptionHandler(error -> { if(error instanceof FatalError) { escalateAndShutdown(error); } else { log.error("this error is ignored", error); } });

registerServiceHealthCheck();

//complete start-up only when successfully connected to database registerHandlerWhenConnectedToDatabase().setHandler(start.future()); }

and clean up when you're done.

@Override public void stop(Promise stop) { databaseConnectionPool.close().setHandler(stop.future()); }

Since verticles operate with their own share-nothing contexts, it is not possible to facilitate direct method-calls of this sort:

@RequiredConstructor public final class OrderProcessingVerticle extends AbstractVerticle

// never reference another Verticle private final OrderMatchingVerticle matching; // or other context than own private final Context parentContext;

private MatchResult match(Order order) { return matching.handle(order); }

Instead, if one verticle wishes to communicate to another it does so by passing a message over EventBus to a specific address.

Using ask:

EventBus Askprivate Future askToMatch(Order order) { // an empty envelope, in which the system relays the final outcome Promise whenReplied = Promise.promise(); //emit event by passing a message and register response handler vertx.eventBus().request("handle-this-order-for-me", order, reply -> { if(reply.succeeded()) { whenReplied.complete(); } else { whenReplied.fail(reply.cause()); } }); //return async result of the whole event-handling return whenReplied.future(); }

Using broadcast:

EventBus Broadcast

By chaining event handlers which may operate in many fully independent contexts, Vert.X framework provides building blocks for creating a complex and performant system which at the same time allows for clean architecture. We argue such a reactive system is easier to reason about than its many alternatives and leaves room to grow your business in times of emergent requirements.

In future posts, we will look at how we solved service encapsulation and why we at Bitpanda Pro love Apache Kafka.

Popular news

How to Set Up and Use Trust Wallet for Binance Smart Chain
#Bitcoin#Bitcoins#Config+2 more tags

How to Set Up and Use Trust Wallet for Binance Smart Chain

Your Essential Guide To Binance Leveraged Tokens

Your Essential Guide To Binance Leveraged Tokens

How to Sell Your Bitcoin Into Cash on Binance (2021 Update)
#Subscriptions

How to Sell Your Bitcoin Into Cash on Binance (2021 Update)

What is Grid Trading? (A Crypto-Futures Guide)

What is Grid Trading? (A Crypto-Futures Guide)

Start trading with Cryptohopper for free!

Free to use - no credit card required

Let's get started
Cryptohopper appCryptohopper app

Disclaimer: Cryptohopper is not a regulated entity. Cryptocurrency bot trading involves substantial risks, and past performance is not indicative of future results. The profits shown in product screenshots are for illustrative purposes and may be exaggerated. Only engage in bot trading if you possess sufficient knowledge or seek guidance from a qualified financial advisor. Under no circumstances shall Cryptohopper accept any liability to any person or entity for (a) any loss or damage, in whole or in part, caused by, arising out of, or in connection with transactions involving our software or (b) any direct, indirect, special, consequential, or incidental damages. Please note that the content available on the Cryptohopper social trading platform is generated by members of the Cryptohopper community and does not constitute advice or recommendations from Cryptohopper or on its behalf. Profits shown on the Markteplace are not indicative of future results. By using Cryptohopper's services, you acknowledge and accept the inherent risks involved in cryptocurrency trading and agree to hold Cryptohopper harmless from any liabilities or losses incurred. It is essential to review and understand our Terms of Service and Risk Disclosure Policy before using our software or engaging in any trading activities. Please consult legal and financial professionals for personalized advice based on your specific circumstances.

©2017 - 2024 Copyright by Cryptohopper™ - All rights reserved.