Fintech Simplified Data Architecture for Order Execution

My Fintech customers are modernizing how they store and process their institutional and retail trades. In the past, their trade applications served high net worth clients with velocity streams of incoming event data of various types, such as feeds, trade data, orders and fulfillment to name a few. This data arrives across any number of nodes across many locations. Typically they would store data in a RDBMS to leverage the relational and durability benefits of products like Oracle or SQL Server. However, at scale a single instance database would struggle to service high volumes of transactions as they are limited to only scaling vertically. To overcome this, inquiry transactions would be offloaded to an async cluster, such as Cassandra, other distributed nosql products, or hadoop fast layers. Sometimes, this alternative has been chosen to offload MIPS costs with trades hosted on Z/OS DB2. More recently, across all of these choices, companies aspire to move to a more resilient data service where node and data center outages would not disrupt the service and provide zero downtime and zero data loss as part of an infrastructure failure. The legacy products such as DB2, Oracle and SQL server would never realize the full resiliency potential due to the complexity of layering in additional asynchronous technologies, brokers to monitor, manual intervention during failover and failback processes. At the end of the day, the complex design would only guarantee eventual consistency across nodes and data centers.

Let’s take a look at the traditional methods below.

Complexity was the biggest challenge to manage with multiple pain points. The architecture before was riddled with cost , operational and regulatory complexity.

• Different databases hold replicas of the same data
• Requirements to query fast-moving dataRegulatory requirements to prove that the different replica databases were all the same, with audited consistency across different data sources

Now, with the simplified approach below, the complexity and risk has been reduced while guaranteeing data consistency across data centers at scale.

Let’s dive into a final state architecture for order trade executions. Logically, we have incoming data, intraday inquiry and adjustments, publishing data downstream to analytics, ODS, etc. All of the replication and data consistency is managed by the CockroachDB cluster via automation utilizing the RAFT protocol. The various physical locations of the nodes, starting with a minimum of three, can be scaled up to as many data centers/regions required to co-locate data closer to users while increasing the tolerance for failure.

The order execution end to end flow is as follows:

Order_1_received -> order_2_submit -> order_3_ack -> 2 order_executions

Each of these steps is made up of implicit transactions for example

This represents an order received:

An order execution appears like this:

These transactions can be entered at any point in the cluster as all nodes are are equal. Each node can perform SQL transactions, which can handle DML and inquire to the schema entities across the cluster.

We have 2 additional requirements around data expiration and emitting all appropriate change events to targets, such as an analytics layer and ODS. To handle this we have enabled a TTL on the rows for all schema entities and enabled changefeeds. These changfeeds will publish all change events to an external source, such as Kafka or sink storage, while protecting the data with a closed timestamp before it can be removed. In my next writeup, I will explore in more detail the multiregional writes and how we can tie the events which are published as transactional.