13. What is scalability in SaaS architecture?
- Scalability is the ability of a SaaS application to handle growing numbers of users, data, and requests while meeting agreed performance targets.
- Vertical scaling increases the power of an existing server. Horizontal scaling adds more servers to share the work.
- The application and its database must support this growth. Adding servers alone may not resolve every performance problem.
- Load testing checks response times, errors, and resource usage under realistic workloads.
- Illustrative requirement: “As usage grows from 500 to 5,000 simultaneous users, at least 95% of customer searches must finish within two seconds under a defined usage pattern.”
14. What is elasticity in SaaS architecture?
Elasticity is the ability to quickly increase or reduce computing resources as demand changes, often automatically. This helps a SaaS application match its capacity to actual usage. NIST definition
- During busy periods: Additional resources help the application handle more activity.
- During quieter periods: Unneeded resources are released, helping reduce infrastructure costs.
- How it works: Scaling rules determine when capacity changes, within configured minimum and maximum limits. Microsoft documentation
Example: A SaaS provider using Azure Monitor autoscale can automatically add server instances when demand rises and remove them when demand falls. Azure example
15. What is load balancing in SaaS architecture?
Load balancing distributes incoming user requests across multiple servers. It helps prevent one server from becoming overloaded while others remain underused. AWS explanation
- Traffic distribution: A load balancer receives requests and selects a server using configured rules.
- Performance: Sharing the workload helps the application stay responsive during busy periods.
- Availability: Health checks identify unhealthy servers so new requests can go to working servers.
- Growth: Additional servers can join the pool and share the workload as demand increases. AWS documentation
Example: A SaaS provider can use AWS Application Load Balancer to distribute website requests across its application servers.
16. What is high availability in SaaS architecture?
High availability means keeping SaaS software working with very little downtime, even when something fails. Downtime is the period when users cannot access or use the software.
To maintain high availability, the system uses extra resources, such as additional servers and database copies. If one fails, another can take over. This switching is called failover.
These resources can be placed in separate locations, so a problem at one location has less impact on the service.
The business decides how much downtime is acceptable and how much it can spend to reduce it, because additional resources increase costs. Microsoft guidance
For example, Amazon RDS Multi-AZ keeps a second database ready in another cloud location. If the main database fails, the second can take over. AWS documentation
17. What is disaster recovery in SaaS architecture?
Disaster recovery (DR) means preparing for and restoring SaaS software and its data after a major disruption, such as a cloud outage or cyberattack.
To prepare, the provider keeps protected backups, which are saved copies of data, and documents the recovery steps. Recovery may involve restoring these copies or restarting the software in another location.
The business decides how quickly the software must return, how much recent data loss is acceptable, and which services should return first. The recovery plan assigns responsibilities and is tested regularly to check that it works. AWS guidance
For example, AWS Elastic Disaster Recovery copies server data to AWS and lets the provider start replacement servers there after an outage. AWS documentation
18. What are RTO and RPO in SaaS disaster recovery?
RTO stands for Recovery Time Objective. It is the maximum acceptable time the software can remain unavailable after a disruption.
RPO stands for Recovery Point Objective. It defines how much recent data the business can afford to lose, measured in time. AWS definitions
For example, suppose the software stops working at 3:00 PM:
- RTO of 2 hours: The software should be working again by 5:00 PM.
- RPO of 15 minutes: Recovered data should include saved changes through at least 2:45 PM.
The business and technical teams agree on these targets based on business impact, cost, and what is achievable. Recovery tests check whether the system can meet them. AWS recovery guidance
