Scalability, Redundancy and Setup planning
ApiOmat provides a broad range of setup types. Three basic setups are described in the Infrastructure Requirements. Except for the light setup, which is used for evaluation and development purposes, all other setups are capable of horizontal scaling at runtime.
The underlying MongoDB is renowned for its scalability and performance even in very large deployments. ApiOmat was specifically designed keeping in mind the performance and scalability requirements.
Hence, each application server handles requests in nearly every case all on its own by connecting to the database or the caching layer. Furthermore, the visual component (Dashboard) can be completely separated from the core (YAMBAS) installation.
Due to the separation and a load balancer managing the underlying application servers, a crashing application server will at the most result in loosing running requests on this server. If an application server is going to a controlled shutdown, no request will be lost. The other way around, an administrator can add new application servers at runtime if the load factor gets to high on the existing instances.
Example Setups
Lite
For evaluation purposes a single server is used, running all three components: Database, Dashboard and YAMBAS. If one component fails, the whole service fails.
Basic setup
A basic redundant setup contains at least two application servers, accessing a replica set of three MongoDB nodes. This setup will work for a moderate load and is built redundantly. Both one application server and/or the DB server can crash at a time.
Enterprise setup
An enterprise setup is used for high redundancy and to secure thousands of requests per second. Depending on the concrete load expectations, a minimum of three application servers are used, accessing a sharded MongoDB cluster with a minimum of five nodes. The number of the nodes depends on the expected load.
Kindly note that the number of app servers depends on the database setup. When using a master-slave replication or more than one app server, the master node is the bottleneck and more app servers may even harm the setup.
As a rule of thumb, more than three app servers without sharding at database level is senseless.