# Deploying Mojaloop
This section details the deployment aspects of the Mojaloop Hub.
# Performance Baseline
The Mojaloop Hub has been demonstrated to support the following performance characteristics on minimal hardware:
- Clearing 1,000 transfers per second
- Sustained for one hour
- With not more than 1% (of transfer stage) taking more than 1 second through the hub
This baseline performance can be used as a reference point for system sizing and capacity planning.
# Deployment of Mojaloop Hub (excluding participant integrations)
The following table provides guidance on which Mojaloop deployment scenario is most appropriate for different user types and use cases.
Deployment Scenario / User type | Learning | Evaluation (choosing Mojaloop) | Use-case Testing | Feature Development and Dev Testing | Production |
---|---|---|---|---|---|
Student | Footprint: Single machine e.g. laptop or single VM. SLA: None | ? | ? | Footprint: Single machine e.g. laptop or single VM. SLA: None | N/A |
Developer | Footprint: Single machine e.g. laptop or single VM. SLA: None | ? | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | N/A |
Business analyst | Footprint: Single machine e.g. laptop or single VM. SLA: None | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | N/A |
Potential adopter | Footprint: Single machine e.g. laptop or single VM. SLA: None | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | N/A |
Auditor / External QA / Security Analyst | Footprint: Single machine e.g. laptop or single VM. SLA: None | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | N/A | N/A |
System Integrator | Footprint: Single machine e.g. laptop or single VM. SLA: None | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Fully redundant, replicated, high availability deployment - On-premises or cloud SLA: High SLA in many areas. |
Hub Operator | Footprint: Single machine e.g. laptop or single VM. SLA: None | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Single machine e.g. laptop or single VM. - Production like environment (sandbox? lower SLA than prod) SLA: - Lower than prod but possibility of testing NFRs. | Footprint: - Fully redundant, replicated, high availability deployment - On-premises or cloud SLA: High SLA in many areas. |
# Deployment Tools
Tool | Features | Minimum Resource Requirements | Security | Documentation | SLA | Caveats, Assumptions, Limitations etc... |
---|---|---|---|---|---|---|
core test harness | - single node - docker-compose - "profiles" available - No HELM - No gateway - No ingress/egress components - No IAM stack - Deploys: - core services & backing services - portals (optional) - monitoring stack (optional) Used in CI pipelines for integration testing. | Mid level laptop or desktop workstation | Zero security | - Developer focused documentation. - Non-technical user documentation to support learning objectives. - Product level documentation to explain features e.g. what it does and where it is appropriate for use | - No SLA | - Never to be used in production. - Never to be used to process real money transactions. |
Miniloop | - single node kubernetes - microk8s? - HELM with string replacements - No gateway - No ingress/egress components - No IAM stack - Deploys: - core services & backing services Gives ability to test in Kubernetes layer. | Mid level laptop or desktop workstation | Zero security | - Developer focused documentation - Semi-technical / BA focused documentation to support use-case experimentation and testing. - Product level documentation to explain features e.g. what it does and where it is appropriate for use. | - No SLA | - Never to be used in production. - Never to be used to process real money transactions. - Possibly useful for testing/understanding of the HELM charts. |
HELM deploy | - Just HELM charts needed to deploy Mojaloop services and backing services. | - High end laptop or workstation - Small cloud kubernetes cluster. | User is required to harden their own Kubernetes cluster. | - Developer focused documentation - Semi-technical / BA focused documentation to support use-case experimentation and testing. - Product level documentation to explain features e.g. what it does and where it is appropriate for use. | - Must be able to achieve SLAs (given baseline hardware specs): - Availability: - ? 4/5 9's? - RTO/RPO: ? As close to zero as possible. - Throughput/Performance - TPS: 1000+ (sustained for 1 hour) - Latency (Percentiles) (excluding external latencies): - Clearing: 99% < 1 second. - Lookup: 99% < second. - Agreement of Terms: 99% < 1 second. - Data management: - Mitigations against data loss i.e. replication, disaster recovery. - Retention (audit, compliance) - Archiving. NB: Strategy is high availability over disaster recovery. | - Can be used in production. - Safe for processing real money transactions. - User/adopter is required to deploy and configure their own infrastructure, including Kubernetes cluster(s), ingress/egress, firewalls etc... - Security is limited to what HELM charts provide. Additional security design and configuration is required. |
IaC | - multiple deployment platform targets - AWS, On-prem, other clouds, (modular) - multiple orchestration layer options - managed k8s, microk8s, eks - GitOps pattern (control centre) - can deploy and manage multiple hub instances / environments - Deploys: - control centre - core services & backing services (options for managed backing services) - portals - IAM stack - monitoring stack - pm4ml - GitOps pattern | - High end cloud or on-premise infrastructure. | Full security | - Multiple levels of documentation targeting all levels of "user". - Developer docs to enable use, maintenance, enhancement, extenstion of IaC capabilities e.g. adding new targets / services / features. - Detailed architecture diagrams and explanation to enable deep understanding. - Tech ops focused docs to enable "infrastructure engineer" level users to use IaC to deploy and maintain multiple mojaloop instances for development, testing and production. - Product level documentation to explain IaC features e.g. what it does and where it is appropriate for use. | - Must be able to achieve SLAs (given baseline hardware specs): - Availability: - ? 4/5 9's? - RTO/RPO: ? As close to zero as possible. - Throughput/Performance - TPS: 1000+ (sustained for 1 hour) - Latency (Percentiles) (excluding external latencies): - Clearing: 99% < 1 second. - Lookup: 99% < second. - Agreement of Terms: 99% < 1 second. - Data management: - Mitigations against data loss i.e. replication, disaster recovery. - Retention (audit, compliance) - Archiving. NB: Strategy is high availability over disaster recovery. | - Can be used in production. - Safe for processing real money transactions. |
# Document History
Version | Date | Author | Detail |
---|---|---|---|
1.0 | 7th May 2025 | Tony Williams | Initial version |