Skip to main content

Scaling

As alluded to in the discussion on Prerequisites, Horizon encompasses different logical tiers that can be scaled independently for high throughput, isolation, and high availability. The following components can be independently scaled:

  • Web service API (serving)
  • Captive Core (ingestion and transaction submission)
  • Database (storage)

As always, scaling encompasses a spectrum. A few common scaling architectures follow.

Single VM​

As a starting point, for development purposes or low load environments with limited history retention (e.g. a few ledger entries), a single VM would suffice.

Low to Medium Load​

For low to medium load environments with up to 30-90 days of data history retention and modest API request traffic, this configuration isolates the database instance from the API service and ingestion process.

Extension: Isolating Captive Core​

Additionally, Captive Core can be further isolated into its own VM, especially for isolating high throughput historical catch-up with parallel workers, leaving it unaffected by API request servicing load.

Enterprise n-Tier​

This architecture services high request and data processing throughput with isolation and redundancy for each component. Scale the API service horizontally by adding a load balancer in front of multiple API service instances, each only limited by the database I/O limit. If necessary, use ALB routing to direct specific endpoints to specific request-serving instances, which are tied to a specific, dedicated DB. Now, if an intense endpoint gets clobbered, all other endpoints are unaffected.

Database instances can be scaled when the I/O limit is reached by using read-only replicated copies that stay in sync and a read/write instance connected to Captive Core. Each DB replica can support a set of request servers to support additional horizontal scaling.

Additionally, a second Captive Core instance shares ingestion load and serves as a backup in case of an instance failure.

Extension: Redundant Hot Backup​

The entire architecture can be replicated to a second cluster. The backup cluster can be upgraded independently or fail-overed to with no downtime. Additionally, capacity can be doubled in an emergency if needed.