You’ve understood it correctly, but let’s not overstate the MPesa case. A hub must enter into an SLA that it can honor. We can’t have an MPesa like volume so consume system resources that all other DFSPs are starved. So by designing for a unit DFSP SLA, the hub ensures equitable admission of transfers from even the smallest DFSPs. The vDFSP concept is just an observation at this point of a way to fit high volume outliers into the unit SLA. It is not the only way or necessarily the best way.
We haven’t characterized the per-DFSP performance degradation when unit DFSP performance design limits (aka the hub DFSP SLA) are approached and exceeded. And we haven’t looked closely at the notification performance architecture or the query architecture to see what other bottlenecks might exist.
Load balancing is possible using the vDFSP concept, but it is not simple to implement. Traffic must be reliably assigned to position bins and the transfer completed within that bin. The number of bins should be dynamic and responsive to presented load approaching the unit DFSP design limit. An algorithm for dynamically growing and shrinking the number of bins, online, while maintaining optimal access times is known as Linear Hashing.
See Litwin from 1980 or so…
The vDFSP concept can be implemented opaquely to the participants. In evaluating the POC architecture, we might ask what additional design alterations we could make that relieve the prepare and position bottlenecks.
It should also be apparent that DFSPs that place a higher load burden on the hub may incur more operating fees than others. And that’s a complex, non-technical calculus to balance the good for the system-using community vs the cost burden of competing institutions with uneven load demands.
I still think it’s about more than the lumpiness of demand. If I’ve understood this discussion correctly, there is at present a hard limit on the throughput for a payer DFSP, which I take to be a consequence of the two pinch points in the current implementation and the PoC: the duplicate check and the liquidity check. You’re certainly right that this can be alleviated by allowing a build-up in demand, provided that this does not result in unacceptable delay; but I imagine that system planners would have factored that in already, and would be planning for maximum demand. That’s certainly how we looked at it in M-Pesa. The problem is, as far as I see, about the implied transferability of spare capacity. If I’ve got a DFSP who’s running at a max load of 200 TPS in a 4-DFSP system, and we re-scale the system to accommodate 8 DFSPs, then the rated capacity of the system has ~ doubled according to our measurement, but the 200-TPS DFSP hasn’t got any more capacity available. So all I’m saying is: it’s easier to understand the capacity of this system if I quote it per DFSP, since that is in fact the limiting factor; and this is true even if we improve the throughput, in this architecture.