Skip to content
Docs
Submit bugs here.
Docs

Please submit any typos you come across to GitHub issues.


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.

Topology 1VM

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.

Topology 2VMs

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.

Topology 3VMs

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.

Topology Enterprise

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.

Topology Enterprise HotBackup

Last updated May. 27, 2022

Page Outline