Our modern architecture provides a HA service across any of our hosting options
HA hosted service and overall design
Cobrowse.io architecture design is based on microservices that sit behind a load balancer and run inside containers alongside a Redis cluster with multiple nodes. These are replicated across multiple nodes/regions for redundancy. The service that handles the in-session streaming runs on the closest geography-optimized regional streaming server for the end user for low latency and it sits behind its own load balancer.
The hosted cloud instances of Cobrowse.io use MongoDB Atlas to provide the database, where high-availability is achieved through multi-site realtime replication across the cluster.
HA for self-hosted deployments
We also provide containerized software for self-hosting in your own AWS/GCP/Azure account or on premise using a single virtual machine or your own kubernetes cluster.
Our public helm chart that gives a good overview of the microservices and scaling: https://github.com/cobrowseio/cobrowse-enterprise-helm. This helm chart can be used standalone, but it’s also the underlying structure for our AWS/GCP/Azure terraform.
Since we use this infrastructure-as-code principle, deploying a HA instance does not require a significant amount of extra development. It is mostly handled through parameter changes in the code.
Our software uses MongoDB as the database, and does not currently ship a database with the helm/terraform self-hosted software (only docker compose does). Each client is responsible for managing the database instance, and any HA requirements. DocumentDB is also supported.
Docker compose can be used in production (we have clients doing this today). In this case, we recommend a fallback instance and database backup strategy. However, for a truly HA setup, we recommend deploying our Helm chart to an on-premise kubernetes instance.