Beamable leverages several technologies and topologies to ensure performance, scalability, and high availability for global game studio customers. If you have specific questions, please address them to [email protected].
Beamable's multi-tenant SaaS offering operates on Amazon Web Services infrastructure hosted from the US-WEST-2 in Oregon, USA. There are failovers to three separate networks with the zone to optimize uptime.
Beamable Private Cloud can be installed into a customer's AWS account in any preferred global availability zone.
Beamable has been tested for global latency. All requests to Beamable services complete on average within 20ms for the actual business logic. Then you have to add the roundtrip time, depending on your location, to US-West 2. This is generally between 60ms and 300ms globally outside of China. Beamable is not accessible from China.
Workloads on Beamable run as EC2 containers on Amazon ECS. All Beamable servers scale elastically, and individually based on workload. They are also designed to accommodate sharp spikes in traffic, both by scaling rapidly and by keeping extra capacity on hand to absorb bursts.
MongoDB Atlas enables us to add shards (horizontal) or vertically augment capacity (e.g., Compute, Memory, Storage) within minutes. We have specifically formated our data to use a sharded cluster (with six total duplicate nodes), so we have redundancy across multiple shards in case of any shard failure. For backups, we use Atlas point-in-time hourly backups so we always have a snapshot of current customer data.
Beamable leverages service plans to bundle infrastructure which can be associated with specific customer accounts. These plans allow us to provision dedicated infrastructure for Enterprise customers, as well as infrastructure in regions closer to customers, or in different cloud providers.
MongoDB and ECS all have secondaries with graceful and automatic failover with graceful deployments and auto-scaling.
Beamable maintains robust logs and metric tracking. We utilize DataDog dashboard and alarms to provide 24/7 year-round on-call support. We have PagerDuty integrated with alert systems and a primary on-call schedule with secondary assignments. All applications have app-level request tracing and metrics to allow for rapid troubleshooting in case of performance degradation.
Any customer environment (Realm) or application that exceeds usage metrics will temporarily receive a request failure with a 429 HTTP status code until such time that capacity has an opportunity to scale up. It is essential to rate limit to prevent cascading effects where one customer can degrade the experience for another and allow time for scaling to occur in situations with a very sharp and unforeseen spike in traffic.
To read an overview of Beamable's security practices that contribute to performance and avilability, please read the overview here.
Updated about 2 months ago