All posts

Why FinecoBank chose & Synadia for it's NextGen stock trade processing layer

Franco Sabini
May 16, 2023
Why FinecoBank chose & Synadia for it's NextGen stock trade processing layer

About FinecoBank

FinecoBank is an Italian bank and stock broker, and my team takes care of collecting orders from our customers through the Internet via different front-ends, validating them against buying/selling power and several regulatory rules, and then forwarding them to the relevant exchanges and back to our trading system.

We have been using a messaging infrastructure for the last 20+ years to manage the order flow among the different processes that are part of our trading platform. Our backend trading platform is written mostly in C++, and we have lately introduced (in part thanks to Golang. We also use bash for scripting, and Python for small tasks.

The problem solves

We have been using TIBCO Rendezvous (RV) for a very long time to solve the above mentioned business requirements. NATS and RV have a lot in common being both subject based, having similar message paradigms.

We first spotted NATS because it covers all our needs such as request/reply, queue subscriptions, and guaranteed message delivery. The wide range of languages supported was also a plus – but it is the low effort required for administration that really nailed NATS as our connectivity platform of choice to build on for the future.

Simplicity is particularly important to us - and while we liked certain aspects of Pulsar, we found it to be more operationally complex. We also didn’t find that it handled request-reply patterns intuitively - which was a very important pattern for us in our legacy TIBCO RV infrastructure.

Being a centralized message broker, it gives us more control over messages. For instance, we now know how many messages are ready to be consumed, the exact application message rate, and so on.

The recently introduced Key Value Store is an incredible addition. We were looking for a key-value cache for many use-cases such as database offloading, stock master data cache just to mention a few. KV fits this needs nicely and is perfectly integrated with the messaging layer.

Our current architecture is composed of two NATS clusters, one for backend applications, the other for frontend. Backend applications widely use JetStream for persistent messages, fire & forget messages and queue groups.

Fineco Bank's JetStream implementation diagram

How we implemented NATS JetStream at FinecoBank

Results and Future plans

Besides using NATS to replace RV, we immediately realized that KV could fit many use cases. JetStream's KV is currently used in production and the customer's account balance to offload to a database. We have also replaced a few html files that were produced by querying real time market data by creating a KV bucket and using filename as key, html as payload. We no longer have to move files around, moreover as soon as the key is created every frontend is notified.

We will be using NATS KV capabilities to centralize users’ market data entitlements (which market data can be received by the customer in real time / delay / none).  KV will allow us a fine-grained permission management over the number of stocks streams simultaneously subscribed, even from different frontends.