Non Performance Requirements of Consumer Data Standards Specification : Open Banking in Australia
Consumer Data Standards (CDS) under Consumer Data Right (CDR) defines set of Non-Functional Requirements (NFR) that needs to be met by Data Holders. The NFR attributes and their threashhold values are shown below.
In order implement and adhere to these NFR, first we need to understand the end to end request response cycle and then break it down at each step. I’m taking a simple banking API request made by an ADR application to get customer account to understand the components involved and typical response cycle. In order understand the behaviour I will break the journey in to 3 stages as listed below.
- Public Internet to API Gateway
- API Gateway and middleware
- Data source(s)
Public Internet to API Gateway
Usually an internet facing application is fronted with a firewall (Web Application Firewall). Firewall establishes a barrier between internal secure network and the untrusted external network : public internet. Load balancer sit next to the the Firewall and route traffic based on the routing policies. Component pattern is shown below with their activities listed inside.
Usually firewall and load balancer performe extremly fast compared to other components on the request response chain. Having sensible set of rules and depth of analysis, and resources available , response time degradation may be negligible, unnoticeable or in-significant.
API Gateway and Middleware
After the load balancer the request lands on a API gateway. API gateway throttles the request based on throttling policies and may reject the request if it has reached the throttling limit. As the second step API gateway need to validate the structural conformance of the request and the payload against the CDS specification. Additionally it needs to support the API queries and versions. Because there might be a situation where data holder need to support multiple versions of the data models of CDS specification.
API Gateway handover the request to an integration module which extract data from original source or from multiple sources. It aggregates and mediates the information extracted. If you look at the time spent on each of the components less time is spent on API gateway compared to integration component (t0-t1 < t1-t2).
Data Sources
Data sources seem to run very slow and seem to have performance bottle neck within the data sources.
1.0 Achieving Minimum Performance Requirements
I have listed minimum round trip time (What ADR experience) from the CDS 1.2.0 specification for each API below.
You may notice that getMetrics() API is not in this table. In order to achieve above round trip times we need to improve the data source performance and employ following tactics.
Caching Static Data
We could target caching product / product details, customer and customer details like static data. Therefore incoming requests may not put load on the data sources. Caching can be enabled at API gateway and as well as on the integration module as shown below.
Employing a Data Lake
Internal banking systems from core banking to digital banking systems can offload data to a data lake implemented on an infrastructure that has more transaction performance.
2.0 Achieving Minimum Availability Requirements
CDS 1.2.0 defines availabilty of APIs to be 99.5% per month. This does not include planned down times. This translates in to maximum of 7.2 minutes unplanned down time for a day.
Availability can be achieved using HA deployment and multi-data center deployment for on premise deployment.
For cloud deployments this can be achieved using multiple availability zones.
As an example Microsoft Azure Cloud guarantees uptime of 99.99% for instances deployed in multiple availability zones as shown below in their SLA.
AWS guarantees the same level of availability under their SLA as shown below.
3.0 Maximum Throttling Requirements
Based on CDS 1.2.0 specification following parameters are used set the threshold.
- Number of sessions per day : the number of individual sessions initiated in a calendar day.
- Transactions Per Second (TPS) : the number of concurrent transactions each second.
- Number of calls : the number of end point calls initiated for a specified duration.
How thresholds work is shown below.
