Scalability Elasticity and High Availability

What you will be able to do

• Explain the five core cloud decisions involved in scalability elasticity and high availability.
• Choose a cloud resource or configuration that matches a stated workload requirement.
• Interpret provider state, workload behavior, and operational evidence before changing broader cloud state.
• Apply an inventory, select, configure, verify, recover, and document workflow to a realistic cloud decision.

01

Build the Cloud Decision Map

Separate scaling, elasticity, load distribution, health replacement, and high availability when designing for changing demand and failures.

Cloud services combine provider-managed layers with customer-controlled configuration. A useful design keeps workload need, resource scope, identity, network path, data, health, cost, and recovery visible instead of relying on a product name.

Start with an inventory and read-only evidence. Record the account or project, location, resource identifier, owner, configuration source, dependencies, expected behavior, and current observation before changing state.

02

Vertical scaling

Vertical scaling changes the capacity of one compute resource by adding or removing processor, memory, or related performance capability. It answers one distinct architecture or operating question within scalability elasticity and high availability.

Use measurements to decide whether a larger resource removes the actual bottleneck. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not resize a stateful workload without checking downtime and rollback behavior. The expected evidence is the resized resource improves the measured limiting signal.

03

Horizontal scaling

Horizontal scaling changes the number of workload instances that can serve demand. It answers one distinct architecture or operating question within scalability elasticity and high availability.

Design stateless handling or explicit state sharing before adding instances. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not add instances when a shared database or queue is already saturated. The expected evidence is multiple instances serve requests with consistent application state.

04

Elastic response

Elasticity adjusts capacity in response to observed or scheduled demand and later releases unneeded capacity. It answers one distinct architecture or operating question within scalability elasticity and high availability.

Define a metric, threshold, stabilization period, minimum, and maximum capacity. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not scale from a noisy signal without testing oscillation and downstream limits. The expected evidence is capacity changes once and stabilizes around the target signal.

05

Traffic distribution

A load-distribution layer sends requests only to eligible targets according to its configured method and health state. It answers one distinct architecture or operating question within scalability elasticity and high availability.

Verify listener, target, health, session, and failure behavior together. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not treat a reachable load balancer as proof that every target is healthy. The expected evidence is requests reach healthy targets and bypass an unhealthy target.

06

Availability design

High availability keeps a service useful through selected failures by removing single points and using independent healthy capacity. It answers one distinct architecture or operating question within scalability elasticity and high availability.

Test one declared failure within a safe environment and observe user impact and recovery. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Stop when replicas share an undocumented dependency or failure domain. The expected evidence is the service remains within its stated objective during the tested failure.

07

Verify One Cloud Change

Before changing cloud state, name the exact resource, required authorization, user impact, expected signal, cost effect, and recovery path. Preview the scope with an inventory or policy view and protect data or configuration that cannot be recreated safely.

Make one narrow change and stop. If the provider response, location, identity, dependency, or effective configuration differs from the plan, preserve that evidence and reassess instead of adding unrelated changes.

A successful API response or portal notification proves only that an operation was accepted. Repeat the original workload path, inspect health and security signals, verify the resulting resource state independently, and remove temporary access or test resources.

08

Recap Before Practice and Prove

Start with vertical scaling. Use measurements to decide whether a larger resource removes the actual bottleneck. Confirm that the resized resource improves the measured limiting signal.

Keep horizontal scaling separate. Design stateless handling or explicit state sharing before adding instances. Respect this boundary: do not add instances when a shared database or queue is already saturated.

Use elastic response as its own decision. Define a metric, threshold, stabilization period, minimum, and maximum capacity. Preserve the resulting evidence.

Before a broader change, review traffic distribution. Verify listener, target, health, session, and failure behavior together. Stop when do not treat a reachable load balancer as proof that every target is healthy.

Finish with availability design. Test one declared failure within a safe environment and observe user impact and recovery. Record the final state, health signal, recovery boundary, owner, and next decision.