Vertical Horizontal and Stateless Application Scaling

01 The idea

The problem this lesson solves

Adding B causes intermittent logouts, while both app health checks stay green.

Prerequisite: earlier lessons introduce the vocabulary and shared examples used here. Follow the module order.

02 Worked example

Follow one worked example

Trace the example in order. Follow the same identities, units and state transitions through the diagram and the events below.

An additional instance helps only when requests can move to it and the constrained resource actually gains capacity.

03 The method

Mechanisms decisions and a guided tutorial

Work through the explanation in order, then apply it in the tutorial. Each comparison names a cost as well as a benefit.

Scale up or scale out

Vertical scaling gives one machine more resources. It can be a useful first move when one instance is undersized, but has hardware limits and may require disruption. Horizontal scaling adds instances and distributes work. It can improve capacity and fault tolerance, but creates coordination, routing and deployment complexity. Find the bottleneck first: adding app servers does not increase a saturated database's write capacity.

Move durable state out of app memory

If A keeps a login session only in its own memory, a request routed to B may appear logged out. Use a deliberately designed shared session store or verifiable tokens with appropriate expiry and revocation behavior. Durable uploads belong in shared storage, not one instance's disk. A local cache is acceptable when losing it causes a recoverable miss. Sticky sessions route a client back to an instance, but failure or rescheduling still exposes the private-state problem.

Scale the tier that is constrained

An app may be CPU-bound, waiting for a database, blocked on a lock or limited by a remote API. Adding app instances helps some of these cases and can worsen others. More callers can increase contention at the same saturated database. Start with where time and queues accumulate, then predict how the proposed change affects that resource.

Vertical scaling often preserves operational simplicity but has a ceiling and can require disruption. Horizontal scaling can add capacity and redundancy, but brings routing, deployment and state-ownership work. Neither choice is automatically more professional; the requirements and measured bottleneck determine the useful move.

Classify state by recoverability

In-flight request variables belong in memory. A local cache may also be private if losing it causes a recoverable miss. A login session, uploaded file or accepted business record that must survive reassignment needs a deliberate shared or durable home.

With local session files, a user can appear logged out when the next request reaches another healthy server. Sticky routing may hide the symptom until a restart or failover. A shared session store or verifiable token design addresses different trade-offs around revocation, expiry and availability; spell out that contract rather than call all state “stateless.”

Test reassignment before claiming elasticity

Start a request on A, route the next to B and remove A. The user action should still work under the stated contract. Also test uploads, background jobs and idempotency records: these are frequent private-state leaks.

An extra replica must be initialized and ready before receiving traffic. Warm necessary data gradually and ensure the shared cache and database can support the larger pool. A scaling event changes connection count and cache behavior even if the application code is unchanged.

Guided tutorial

1. List state

Inventory session data, uploads, local caches, jobs and accepted operations.

2. Label recovery

Mark each item as disposable, reconstructible or durable.

3. Move one request

Trace two requests from one user reaching different instances.

4. Identify the bottleneck

Choose a measurement that would justify app scaling instead of database work.

request state: private, short-lived
local cache: replaceable, misses are recoverable
session / accepted work: explicit shared or durable authority
upload: durable object storage or another shared contract
scale decision: measured bottleneck + surviving capacity

04 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

05 Where & why

Check the primary references

Use official references for protocol and implementation details. The questions here are teaching prompts.

06 Interview questions

Explain the reasoning out loud

Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.

07 Practice problems

Practice a new case

Solve the new cases before revealing hints. Complete worked solutions follow the set.

Worked solutions