Scaling Guidelines
What is a scaling strategy?
A scaling strategy involves:
Customers: who are aware of and manage their account limits according to their needs;
Licensees/Sub-Licensees: who adopt limits and help customers choose the correct tier; and,
Everyday Digital: who sets limits and provides infrastructure accordingly.
Choosing the right tier
Users are not the only criteria for the customer to consider when choosing the right starting tier. Maximum users are the exponential factor applied to resources such as logs, content, and concurrency. This can mean that sometimes a customer may have a small amount of users, but a large amount of content and, therefore, the log size is the scaling metric that should be considered when determining the optimal tier.
A simple formula for determining log size is as follows:
Log Size = Number of users X (Total Pages + Total Pathway Activities)
Available Tiers
Examples
Scenario 1: A B2C / Learning App
A customer wants to launch a public-facing app. The app's initial launch will likely only require a small number of users. The customer expects that they will acquire 250 new users per month, and will have about 100 page activities (articles, module pages) and 50 activities in pathways.
In this scenario the user metric will be the scaling factor as the amount of content is relatively small. This means that the log size does not exceed the recommended tier for the amount of users.
Scenario 2: B2C / Learning App
This is similar to Scenario 1, except that the amount of content is much higher. In this scenario, we are likely going to need to use the log size as the scaling factor.
In this example, we see that due to the log size, the customer’s account scales at a much lower user volume than in the previous example. This highlights the importance of looking beyond the number of users and taking into account the content volume metric.
Proposal Guidance
When a licensee is engaging with a potential (or existing) customer, it is important to dispel some misconceptions and allow the customer to make informed decisions about tiers and scaling. Part of the process should be an evaluation of their requirements and educating them on which tier would be appropriate for their needs. SaaS platforms often appear to the public as endless resources that scale without cost, this is not true.
Even websites have scaling requirements which are based on the number of users, how much content, and concurrency. Websites that have high traffic cannot be hosted in tenancy (virtual) environments and need sophisticated infrastructure spanning multiple regions. This is the same for customers using the platform.
When engaging with a customer, a questionnaire needs to be filled out that covers the following:
Initial/anticipated number of users in the first month?
Number of user acquisitions per month?
Number of active users per day?
Anticipated peak times during the day?
What percentage of users are likely to be on-app during peak times?
How many pages of content?
How many pathway activities?
Retention requirements?
Based on the answers to the questions above a number of scale approaches can be applied:
Evaluating both user and log size metrics to determine when and what tier should be applied.
User retention factor (see User Retention below)
Determining concurrency requirements (see below)
User Retention
User retention is not only important for privacy best practice, but can also create savings on scaling costs for customers. This is another factor that customers should be educated on. If the customer only intends to retain users' data for 6 months, this can affect the number of users and therefore log size in the scaling strategy. Using scenario 2 above, let's assume that new users are likely to only use the app for a month and that user retention is set to 3 months. This would mean that 3 months post the app launch, 250 users will be deleted every month.
In this scenario, the customer does not need to scale to a dedicated environment and can remain as a tenancy.
Concurrency Requirements
Concurrency requirements can be easily achieved on dedicated environments (Standard, Pro, Enterprise tiers) as they are isolated to dedicated resources. With multi-tenancy platforms, this is more complicated, as it depends on:
Number of tenancies on a single platform?
Number of active users?
Content volume (log size)?
Enterprise Platform Scaling
Multi-tenancy accounts are on enterprise environments which allow for:
1 TB of storage
25 Million logs
25,000 users
When Licensee/Sub-Licensee platform thresholds are passed, concurrency issues are likely to occur at peak times. At double the capacity, there is a risk of outages during peak times. By understanding the limitations of an enterprise instance we can determine how many tenancies can exist comfortably on one platform. A rule of thumb is to work within 80% capacity.
Whether it is a licensee multi-tenancy platform or a customer, running through scenarios like the above, helps determine when a platform is reaching its capacity.
Scaling options
Licensees/Sub-licensees benefit from additional enterprise instances at a discounted value of R35,000. This would allow a licensee to expand into an additional server either as a new instance or extend the current instance (multi-server).
Evaluate your existing customers and determine who needs to scale into a dedicated environment (upsell/upgrade opportunity).
Licensees, sub-licensees and customers on dedicated environments can enable user retention / auto-deletion which would regularly lower the user numbers and log size.
Load Balancing Tenancy Accounts
What is load balancing?
Within an Enterprise account, load balancing can be achieved by enduring overages on one tenancy account at the expense of another. For instance, one tenancy may only take up 150% capacity, but this is balanced by only having 50% capacity on another tenancy.
How can I load balance accounts and what are the risks & conditions?
Licensees, Sub-Licensees & Enterprise accounts may opt to load balance accounts to provide more capacity than the recommended tenancy thresholds. While we do not recommend doing this, we can provide some basic rules to follow to ensure that a tenancy account does not bottleneck resources:
We do not recommend allowing an account to be more than 200% capacity.
We do not recommend load-balancing accounts if the server capacity is 70% or above.
We do not recommend allowing more than 25% of tenancy accounts to be load-balanced.
Load-balancing comes with risks, and licensees should understand that if an account creates a bottleneck, they will need to scale down the account or migrate to a dedicated instance to resolve issues.
Incorrect Tier Risks
Allocating accounts to the incorrect tier can lead to several potential risks:
Performance Issues: If an account is allocated to a lower tier than required, they may experience performance issues such as slow loading times, lags, or even system crashes during peak usage times. This could lead to customer dissatisfaction, and potentially loss of business.
Data Storage Issues: If the allocated tier doesn't provide enough storage for a customer's needs, they may run out of space, leading to potential data loss or the inability to store more data. This could disrupt their operations and lead to dissatisfaction.
Inefficient Resource Utilisation: Allocating accounts to the wrong tier can lead to inefficient use of your resources. If customers are using more resources than their tier allows, it could strain your system and negatively affect other customers. Conversely, if customers are underutilising their allocated resources, you're not maximizing your potential revenue.
Reputation Damage: Consistent issues with performance, overcharging, or data loss can lead to a damaged reputation for your business. This could affect your ability to attract new customers or retain existing ones.
Increased Support Costs: Customers on the wrong tier may require more support, leading to increased costs. They may need assistance with performance issues, or data storage problems, all of which require time and resources to resolve.
Multi-Tenancy Risks
In a multi-tenancy environment, multiple customers share the same server resources. If a high-volume tenancy that should be on a dedicated tier is instead placed on a shared server, it can lead to several potential issues:
Resource Strain: High-volume tenants require more server resources. If they are placed on a shared server, they could consume a disproportionate amount of resources, leaving less available for other tenants. This could lead to performance issues for all customers on the server.
Performance Degradation: The high demand from a large tenant could lead to slower response times, increased latency, and potentially even downtime for other tenants. This could disrupt their operations and lead to dissatisfaction.
Security Risks: While multi-tenancy environments are designed to be secure, placing a high-volume tenant on a shared server could potentially increase the risk of security issues. For example, if the high-volume tenant is targeted by a cyber attack, it could potentially impact other tenants on the same server.
Compliance Issues: Some high-volume tenants may have specific compliance requirements that cannot be met in a shared environment. For example, they may require data isolation for privacy or regulatory reasons.
Customer Churn: If other tenants experience performance issues or security concerns as a result of the high-volume tenant, they may choose to leave, leading to customer churn and loss of revenue.
To avoid these issues, it's important to carefully assess the needs of each tenant and allocate them to the appropriate tier. High-volume tenants should be placed on dedicated servers to ensure they have the resources they need without impacting other customers.
Scaling Questionnaire Template
User Scaling
These questions will assist in determining the expected user growth, recommended starting tier, and forecasting tier upgrades.
What is the initial or anticipated number of users in the first month?
Used to recommend starting tier
How many users do you expect to acquire each month?
Used to forecast tier upgrades based on user growth
What is the estimated percentage of active users per day?
e.g. 100%, 80%, 60%
What are the anticipated peak times during the day? (For example: 24 hours, 12 hours, 6 hours, or 3 hours)
Used to understand the duration of resource usage.
Resources
How much storage in GB do you estimate your assets will require?
Images, Videos, Scorm Files, Audio
How many content pages, Scorm packages, PDFs, Powerpoints, or articles do you estimate you will create?
How many pathway activities do you estimate you will create?
The above two questions allow for determining starting/upgrading tiers based user to content ratios (Log Size)
Auto-User Retention
By default, licensee platforms set the maximum number of months an inactive user’s data will be retained. Custom auto-user retention settings are only available on Standard, Pro, and Enterprise tiers.
Do you need to implement auto-user retention that is different from the default setting?
Answering yes will require a dedicated/enterprise tier.
If yes, what is the maximum number of months the platform will retain user data?
Concurrency
Concurrency is the platform's capacity to handle a number of users over a measure of time. Custom concurrency requirements are only available are only available on Standard, Pro, and Enterprise tiers.
Do you have a concurrency requirement?
Provide the number of users over a duration of time. For example: 5,000 per 10 minutes; 10,000 per 5 minutes; 4,000 per 30mins.
If yes, please answer the following questions:
What is the estimated percentage of users you will need to support concurrency at peak times?
e.g. 100%, 80%, 60%
Will your concurrency requirements need to handle users from multiple regions? Please provide the region and estimated number of users.
Depending on the number of users per region, regional deployment may be required which is available on enterprise tiers and above.
Last updated