Why financial backends are hard
Building a financial backend means solving some of the hardest problems in distributed systems while meeting strict compliance requirements.
Every transaction must be correct
There can be no lost writes or double-counting. A single error can mean regulatory violations or lost money.
Complete audit trail
Regulators require a full, ordered record of every event. Retrofitting audit logging onto an existing system is fragile and error-prone.
Cross-service consistency
A transfer touches balances, ledgers, and limits simultaneously. Coordinating these across services with sagas or two-phase commit adds enormous complexity.
Replayability and recovery
When errors are found, you need to reconstruct exactly what happened and recompute derived state from the ground truth.
Why Rama for finance
Cross-partition ACID transactions
Updates across the entire cluster commit atomically with exactly-once semantics. No distributed transaction coordinators, or saga patterns.
Built-in audit log
Every event is permanently stored in an ordered log. The audit trail isn't a separate system bolted on after the fact. It's the foundation everything else is derived from.
Replayability
Because the complete event history is stored, you can recompute any derived state from scratch. Fix a bug in your calculation logic, replay the events, and all your data is corrected.
All views from one source of truth
Balances, transfer history, risk aggregations, and reporting views are all derived from the same events. No reconciliation jobs, no inconsistent replicas, no data synchronization between separate systems.
Bank transfers at scale
Cross-partition ACID transactions with exactly-once guarantees. Fault-tolerant fund transfers in 50 lines of code, scaling linearly across nodes.
| Cluster size | Transfers/sec? | Initiation (p50)? | Initiation (p99)? | Completion (p50)? | Completion (p99)? |
|---|---|---|---|---|---|
| 2 nodes | 34,700 | 2ms | 23ms | 125ms | 220ms |
| 4 nodes | 66,100 | 2ms | 26ms | 130ms | 220ms |
| 8 nodes | 126,000 | 4ms | 31ms | 150ms | 300ms |
| 16 nodes | 243,800 | 4ms | 41ms | 240ms | 490ms |
| 32 nodes | 460,200 | 5ms | 45ms | 350ms | 720ms |
Tested on AWS i8g.xlarge instances (4 vCPU, 32GB RAM)
Each transfer debits one account and credits another with full ACID guarantees across partitions. The complete implementation is 50 lines of code.
View the codeRUN THE BANK TRANSFER EXAMPLE LOCALLY
rama-demo-gallery contains BankTransferModule, the exact code behind the benchmarks above, along with many other self-contained examples of building applications with Rama.
git clone https://github.com/redplanetlabs/rama-demo-gallery.gitcd rama-demo-gallerymvn test -Dtest=BankTransferModuleTestRAMA IN FIVE MINUTES
See how Rama integrates databases, caches, queues, and processing into a single system where you only write business logic. This post walks through an example showing how a traditional Postgres-based architecture accumulates complexity while Rama keeps everything simple.
Join our Discord
Join the Rama Discord community to ask questions and connect with other developers
Join Discord