Quick recap
The team discussed the responsibilities of the Design Authority (DA) in maintaining the reference architecture and focusing on performance characterization tests, the potential of modifying the system to allow version 7 UUIDs in resource identifier fields. They also addressed concerns about the security bounded context in the vNext implementation potentially not aligning with some TGB directives, the need for more detailed design documentation for the vNext implementation, and the decision-making process of the DA (Design Authority) in general.
Summary
DA Calls, JWS, and Reference Architecture
James clarified to Min that DA calls are not open to observers unless specifically invited, which was a misunderstanding on Min's part. James confirmed that Min could be invited to future discussions about the JWS certificate and the reference architecture by a DA member. The postponed discussion on the JWS certificate and reference architecture was rescheduled for the following week. The main discussion item was about the responsibilities of the Design Authority (DA) in maintaining the reference architecture. Paul suggested reviewing the current state of the documentation to identify gaps for improvement
Performance Characterization and UUID Bottleneck
Kalin presented the results of performance characterization tests on their system, highlighting that the goal was to ensure reasonable performance throughput with standard hardware. Paul clarified that this was not about achieving the highest transaction per second. Kalin then identified a significant bottleneck caused by the use of UUIDs as primary keys in several tables, which was degrading index performance and consuming memory. Kalin proposed potential solutions such as using a different version of UUID and implementing as binary(16) in table storage, and suggested exploring new UUID formats proposed, specifically designed for database use.
Analyzing UUID Performance and Simulation Issues
Kalin and James analyzed the performance of different versions of a UUID, focusing on versions 4 and 7. They found a significant drop in performance for version 4, attributing it to its use in a secondary index. The performance of version 7 was found to be stable over time due to its sequential nature. They also discussed an issue with their simulation testing involving multiple simulated DFSPs, where all simulators ran on the same VM, leading to highly sequential generated UUIDs. To address the performance degradation due to use of non-sequential UUIDs, they proposed to modify the validation code to only allow version 7 UUIDs and add validation to certain parts of the system.
Discussing UUID Modifications and Performance
The team discussed the potential of modifying the system to allow version 7 UUIDs, which would be less restrictive but would require approval from the Change Control Board. James highlighted the possible impact on performance and cost, suggesting that the decision should consider the system's bottom line. Paul Baker recalled a previous discussion about the uniqueness and independence of UUIDs and their importance for the system. Karim proposed an alternative approach where each participant generates a unique ID, suggesting that non-enforced uniqueness could be a solution to the performance issue. The team left with an open question about whether this alternative approach could be a viable solution.
UUIDs, API Limitations, and Pattern Checking
Karim and James discussed the issue of UUIDs not fitting certain fields in the ISO-20022 API and possible solutions, including the potential use of CUID in the next version of the Mojaloop API. They agreed to further investigate this matter in future Change Control Board meetings. The team also discussed the need for pattern checking and validation to ensure good performance, with Kalin proposing to relax the pattern on the quoting service and update the SDK to generate UUID version 7. No objections were raised to this proposal.
Reference Architecture and TGB Directives
James and Paul discussed the reference architecture, with Paul expressing concerns about the security bounded context not aligning with some TGB directives. James agreed, noting the lack of well-defined documentation and implementation guidelines for the reference architecture. He emphasized the need for a clear translation from the high-level map into requirements or guidelines for any implementation. Paul concurred, highlighting the importance of a ubiquitous language in the process. James also pointed out a possible omission in the terminology regarding the scheduling for timeouts and notifications, indicating this as an oversight.
Improving Mojaloop Project Documentation
James expressed his concerns about the current state of the Mojaloop documentation, highlighting the need for more detailed design and implementation documentation beyond the high-level reference architecture. He suggested using the beta version of the vNext implementation as a starting point for this documentation. Karim clarified James's concept of 'implementation architecture', emphasizing its focus on non-functional properties of the system and its bottom-up view. James agreed, noting the complexity of defining architecture at various levels. They both agreed on the need to specify these aspects further.
vNext Beta Codebase Diagrams and Tool Choice
James proposed creating a diagram to illustrate the major constructs within each bounded context of the Vx Beta codebase. Paul agreed to this idea and suggested that James should also consider the interface protocols. James further discussed documenting design and code review guidelines and to provide more descriptive information on tool choice. Paul emphasized the importance of tool choice, highlighting the need for enterprise support and maintained Helm charts. James agreed and noted the value of product input in the reference architecture space.
Next steps
- Aung will invite Min to the vNext call next week to discuss the JWS certificates vs raw keys issue.
- Paul Baker will lead a discussion on the responsibilities of the DA in maintaining the reference architecture, including reviewing the state of the documentation and identifying gaps.
Please note that this content was originally generated by AI but has been reviewed for accuracy by James Bush
Top comments (0)