Overview

This section sets out system sizing recommendations for both the Private Network and Rayls Sovereign infrastructures in the Rayls Ecosystem, so that the system performs as expected across different environments, production and testing included.

---

Private Network Infrastructure

The Private Network is a permissioned blockchain network optimised for privacy and scalability. The minimum requirements for each key component of the Private Network infrastructure are set out below:

Rayls Sovereign ledger Infrastructure

The Rayls Sovereign ledger carries secure, private financial transactions and integrates with the wider Rayls Ecosystem. The minimum system requirements for each key component of that infrastructure are set out below:

---

MongoDB

MongoDB is the core database manager for Rayls, and its sizing depends both on the chosen architecture and on how many Rayls components, meaning Rayls Sovereign ledgers and Relayers, share the same instance or cluster.

A standard MongoDB setup running on 4 vCPU and 16GB of RAM is usually enough to start with one Rayls Sovereign ledger and one Relayer without hitting performance bottlenecks. Disk size depends on how many transactions flow through the Rayls Sovereign ledgers and how many blocks the Relayer imports, and 100GB is a reasonable starting configuration.

In production environments it is worth monitoring database disk consumption closely and enabling auto-scaling where the platform allows it. One option is a cloud-based managed service such as MongoDB Atlas, which provides scalability features out of the box.

Read more in MongoDB Documentation.

PostgreSQL

The Postgres database manager supports the Flagger, the Listener and the Governance API components, and it requires at least 2 vCPU with 4 GB of RAM. Most of the sizing remarks made for MongoDB apply here too, and 100GB is again a reasonable starting point.

Read more in PostgreSQL Documentation.

---

Scaling Considerations

For both the Private Network and Rayls Sovereign, the infrastructure scales vertically and horizontally depending on system load and transaction volume.

• Vertical Scaling: As transaction volumes increase, components such as MongoDB and Relayers can be scaled vertically by adding CPU and memory to existing nodes, which sustains performance and avoids bottlenecks.
• Horizontal Scaling: In production environments, scaling MongoDB into replica sets or using a managed cloud service such as MongoDB Atlas is recommended, since both support automated scaling and replication.
• Storage Scaling: MongoDB and Private Network Hub storage grows with transaction volume, so automated storage scaling should be put in place where possible to prevent failures caused by storage limits. Cloud-based services frequently offer elastic storage options.