Backend#4: A database built for financial transactions, data plane and control plane in transaction processing and application caching
A database built for financial transactions
TigerBeetle is a database that focuses on financial transactions with a redesigned distributed storage engine and consensus protocol for the OLTP workloads, which makes it significantly more performant than the general-purpose OLTP databases.
Since the database is built for financial transactions, it comes with in-built features associated with online transactions, such as debit credit design, double-entry accounting, multi-tenant currencies, net balance limits, two-phase transfers, strict serializability and so on.
In addition, it has the capability of processing thousands of debit/credit transactions in a single query and leverages the protocol-aware recovery approach to survive storage faults.
How does it fit in our system architecture?
TigerBeetle DB in our system architecture
As opposed to taking this database as a replacement for our conventional or general-purpose OLTP databases like MySQL & PostgreSQL, we can make it work alongside them.
TigerBeetle should be used in the data plane to implement the money-related features, while our general-purpose databases should be used in the control plane for storing information or metadata that is updated less frequently.
Let's discuss this further.
Data plane and control plane in transaction processing
The data plane, also known as hot path, involves system components that handle real-time, high-volume transaction processing. This is the plane where high-frequency data manipulation happens.
Speed and reliability are critical here and TigerBeetle is leveraged in the data plane to handle real-time transactions with high throughput, concurrency, consistency and durability.
The control plane, in contrast, involves system components that manage state, metadata and system configuration. Components in this plane may not require the same level of performance that components in the data plane require.
We can setup our general-purpose OLTP databases in the control plane to handle the metadata such as transaction info, users, configurations, and other stateful data that need not be accessed or modified as frequently, in addition to system state, configuration, reporting and analytics.
The control plane is usually less performance-critical compared to the data plane since its operations are more about management and coordination rather than handling the actual user data or requests directly.
The data plane needs to be highly optimized for performance, reliability, and scalability, as it directly impacts the end-user experience. It deals with real-time data and often requires stringent SLAs (Service Level Agreements) to ensure low latency and high throughput.
The term 'plane' primarily represents the separation of concerns within a system. The conceptual separation helps in understanding and managing the complexity of the system. By separating the components into different planes based on the criticality of latency, throughput and such, we can optimize our system for performance, scalability and resource allocation.
Running transaction logic in the database as opposed to the application layer
Typically, we have the transaction business logic implemented in the application code and the database focuses on persistence, but TigerBeetle performs all balance tracking logic and accounting in the database since it comes with financial transaction-related features out of the box. This enables the application layer to be stateless.
In addition, it supports batching by design where transfers or commits in fixed or dynamic time windows can be batched to send them in a single network request for performance.
There are a bunch of other performance hacks that the database pulls off, but I am holding onto them till my future posts as I want to delve into them in detail.
Furthermore, this is a good resource on their website if you wish to understand the fundamentals of debits and credits, double-entry bookkeeping, etc. and implement these concepts in your Fintech app.
Application caching
Here is a quick list of different components or places where the data is cached in our applications for performance:
Database integrated cache
This is a cache built into the database system and is managed by the database, enabling the DB to cache frequently accessed data.
Local or in-memory cache
This cache resides in the application server and averts the need to hit the database to serve every request.
Cluster in-memory cache
The scope of local or in-memory cache is limited to the single application server instance. To enable the service run in a cluster maintaining a consistent state, we need a distributed cache that spans multiple nodes, enabling the service to scale.
External database cache
This cache is deployed separately between the application server and the database and intercepts requests hurtling toward the database. It serves the frequently accessed data and averts every request hitting the database, thus reducing its load.
There are other forms of caching in an end-to-end application architecture; we will discuss those in a more detailed diagram in my future posts.
This AWS resource on caching challenges and strategies is a recommended read on caching.
I hope you found this post insightful. If you did, please do share it with your network for more reach. You can connect with me on LinkedIn & X, in addition to replying to this post.
If you wish to learn software architecture from the bare bones, check out the Zero to Software Architecture Proficiency learning path that I've authored that educates you, step by step, on the domain of software architecture, cloud infrastructure and distributed system design.
I'll see you around in my next post. Until then, Cheers!