## 7 Scalability Study
### Impact of Transaction Load
#### 7.2.3 Findings of the Scalability Study  
The results of the scalability study have shown that the volume of data contained in an invoice has no discernible effect on the performance of the Smart Money system; therefore, the design and implementation demonstrate scalability. This finding indicates that there is no restriction as to which businesses can participate in this scheme as sellers with respect to the volume of goods that can be sold in a single transaction. For example, a shopping list in a supermarket is commonly larger compared to a shopping list from a clothing store. It also proves that MTS can be used not just for retail but also for wholesale transactions, where the quantity of goods exchanged can be much higher. Moreover, the Smart Money system can cope with increasing numbers of clients. The system can retain a certain level of transaction throughput, but the latency of each transaction increases with the number of clients, albeit linearly, and, therefore, in a scalable manner. This shows that MTS is applicable to existing payment systems which have to support a very big number of endpoints (e.g., point of sales systems).  
From inspection of the results, it is observed that increasing the data volume generated by each client has much less of an effect compared to increasing the number of clients. Since clients are external and communicate via RPC calls, each additional client introduces more network communication overhead. RPC calls involve serialization/deserialization, network latency, and processing time on the server side, all of which contribute to increased latency. Also, as the number of clients increases, DLT nodes may experience resource contention (CPU, memory, and I/O). Handling more simultaneous RPC calls can lead to queuing delays and increased processing times per transaction.  
The results also show that the Smart Money system scales well when the transaction load is increased, either when increasing the number of clients or when increasing the volume of transactions generated by each client. This is a requirement of modern payment systems which incorporate new forms of money such as CBDC, which will take up an even larger proportion of daily payments as physical cash and theques are being abandoned. Issuing an invoice is faster than paying for an invoice. This is caused by the extra computational overhead for the additional calculations and necessary checks, e.g., check if it is an un-paid invoice, check if the funds required are available, check if this invoice can be paid (see Figures 4 and 5). These steps are executed serially and are mandated for a CBDC payment infrastructure; thus, they cannot be eliminated. However, a technical solution for mitigating the delays associated with paying an invoice compared to issuing, would be the parallelisation of the checks that are currently implemented serially. This parallelisation would be manifested within the Corda flow that implements the payment; however, this feature is not provided by the R3 Corda framework.  
Overall, the design has been demonstrated to be scalable within the simulation environment and the constraints of its hardware as described in Section 5.3.