Vertical vs horizontal scaling

Think about where user session data lives.

Model answer.

Vertical scaling (scale up)

• Give the existing server more resources: more CPU cores, RAM, faster disks.
• Pros: no code changes; simple to operate; no distributed-system problems.
• Cons: there is a hardware ceiling; large machines get disproportionately expensive; the single machine remains a single point of failure; upgrades often need downtime.

Horizontal scaling (scale out)

• Add more servers and spread traffic across them, usually behind a load balancer.
• Pros: near-linear capacity growth for many workloads; tolerates individual server failures; can add or remove machines as traffic changes (auto-scaling in the cloud).
• Cons: more moving parts — load balancing, deployments across many nodes, monitoring, and data consistency across machines.

What must change for horizontal scaling

• Make application servers stateless. If user sessions are stored in one server's memory, a request routed to a different server will not find them. Move session data to a shared store (e.g. Redis) or use signed tokens such as JWTs that the client sends with each request.
• Externalise file storage. Uploaded files (e.g. ID photos) should go to shared object storage, not the local disk of one server.
• Use a load balancer with health checks so traffic only goes to healthy instances.
• Plan for the database. Stateless app servers scale easily; the database often becomes the next bottleneck. Common steps are caching, read replicas for read-heavy traffic, and eventually sharding.
• Background jobs (emails, receipts) should go through a queue so any worker can process them.

Typical path in practice: scale vertically first while it is cheap and simple, then scale out the stateless tier, then tackle the data tier.

Common follow-up: "Can sticky sessions avoid making the app stateless?" They can route a user back to the same server, but if that server dies its sessions are lost and load can become uneven — a stopgap rather than a real solution.