The PlayToTV platform has been designed with scalability and robustness in mind as the primary design goals. PlayToTV’s architecture uses 6 core components: gatekeepers, core servers, push servers, database servers, messaging servers and async processing servers.
PlayToTV can be set up without any single points of failure. Even with a limited amount of physical machines a lot of fail-over and redundancy is built into the overall system to make sure applications running on the PlayToTV platform can host high loads and do so consistently and reliably while maintaining an acceptable quality of service.
See below for a more detailed technical overview.
The gatekeeper servers are the first point of contact for PlayToTV enabled clients and are primarily responsible for maintaining an acceptable quality of service and balancing clients across all available servers. Gatekeeper servers do so by providing clients with a list of web service endpoints if, and only if, maximum capacity is not reached. If maximum capacity is reached the client is notified that the service is at capacity. Maximum capacity in this context is either the maximum licensed capacity or the highest possible capacity at which the periodically measured quality of service (QoS) remains acceptable, whichever is reached first.
Once a client passes the gatekeeper server it will start talking directly to the other services. This architecture ensures that even overloaded gatekeeper servers will not interrupt or degrade the service for consumers that are already connected to the platform.
The core PlayToTV services are RESTful Web Services that expose all PlayToTV functionality to connected clients through a public API. The API uses standard HTTP requests and JSON (ww.json.org) as its data format.
Clients are expected to remain sticky to one specific core service instance until that instance becomes unavailable or request roundtrip times reach a certain maximum indicating the instance is under more load than it can comfortably handle. This stickiness allows for user specific instance local caching to be as effective as possible. All state other than instance local caching is distributed and does not require clients to remain on a specific server instance. In other words, instance stickiness is an optimization rather than a requirement.
The PlayToTV makes heavy use of processing non-critical workload asynchronously using workload queues and consumers, typically processed by dedicated instances to offload the servers that are performing application critical operations. This allows for more efficient use of available hardware resources as well as avoiding issues with non-critical operations interrupting or degrading critical ones.
Work that typically qualifies as non-critical are various forms of data aggregation, real-time statistics on a best effort basis and user specific notification such as friend, achievement and other notifications.
Additionally, job scheduling is used for automatically triggering interactions for prerecorded shows as well as internal monitoring and housekeeping.
The PlayToTV push servers are server instances dedicated to pushing notifications and state updates to connected clients. The push servers are highly optimized servers that use WebSockets as the preferred technology with HTTP polling as a fallback for client platforms that do not support WebSockets.
Push server are isolated from the core server instances because they are specifically optimized to push data to all or to large groups of connected clients in an as short as possible amount of time. On a cluster with loads below maximum capacity it can generally be guaranteed that push data reaches all clients within 1 to 2 seconds after a director triggers an event or interaction.
All services use the PlayToTV persistence cluster for data storage and retrieval. The persistence cluster consists of two or more servers that host instances of our document database. The database cluster can be configured in such a way that there are no single point of failure throughout the entire persistence solution.
The PlayToTV platform was designed to be hosted on cloud environments in order to be able to easily scale up and down to a specific target capacity.
Given the nature of most play along concepts where the service is only required to up for a limited amount of time, say an hour every day or week, the cloud computing approach also reduces hosting costs since it allows you to pay for server resources only during times when these resources are actually required. Ex Machina typically requires between 1 and 2 hours setting up all instances and warming up the system and load balancers. In frequent or continuous use scenario’s PlayToTV can also be deployed on servers that are permanently available.