SysPad › Examples › Open-banking API backend
Open-banking API backend
A partner-facing open-banking API: API Gateway (REST) with caching + a Cognito authorizer, a core-banking engine on EC2/EBS, RDS Proxy in front of Aurora, KMS + Secrets Manager as side-calls, and a Step Functions approval saga for wire/loan requests.
KMS/Secrets Manager wired correctly as side-branches (they have no output port), tuned with realistic cache-hit rates, plus a low-volume Step Functions saga branch.
- Throughput: 3,000 req/sec
- First to saturate: Nothing at this load
- Estimated cost: $91k/mo
How it works
- Open Banking API
- REST rather than HTTP API, for the response cache and the Cognito authorizer. A 20% hit rate is honest for partner traffic where most calls are account-specific and cannot be shared.
- Core Banking Engine
- Still on instances rather than containers, which is the usual compliance answer: a fixed fleet with a known patch state and an audit trail per host.
- RDS Proxy
- Multiplexes the whole engine fleet onto a pool of 200 database connections. Without it the connection count, not CPU, is what would fail first on the ledger.
- KMS
- A side-call, not a hop: nothing flows through it, so it has no output port. Caching data keys 97% of the time is what keeps it far below the request quota.
- Approval Saga
- Wire and loan approvals are long-running and must survive a restart, so they run as a state machine outside the request rather than as a thread holding a connection open.