Vertical vs horizontal scaling
Vertical scaling makes one server bigger; horizontal scaling adds more servers and shares the work between them.
See it
What it is
Vertical scaling means giving one machine more CPU, memory, or storage. Horizontal scaling means running more machines or replicas and spreading traffic across them. Scaling up is often the simplest answer for a database or early product; scaling out adds capacity and can survive one replica failing.
Reach for vertical scaling while one host still has affordable headroom and the software is hard to split. Stack Overflow is the standing counterexample to the reflex that serious traffic demands a fleet: for years it published its architecture and served a top-100 site from a handful of deliberately oversized machines. Reach for horizontal scaling when traffic changes quickly, one machine is no longer enough, or availability requires redundancy.
Every machine has a ceiling, and resizing it may require a restart. More machines add their own bill: shared sessions, coordinated deploys, a load balancer, and a database that can handle all the extra callers. Stateless application servers are much easier to scale out than local files or memory.
Ask AI for it
Refactor this service for horizontal scaling on Kubernetes. Keep request state outside the container, add CPU and memory requests and limits, run at least two replicas behind a Service, and create an autoscaling/v2 HorizontalPodAutoscaler targeting 70 percent average CPU with conservative scale-down behavior. Include a short comparison with the vertical option of increasing the existing pod's resource requests.