Scale up until you cannot
Scale up until you have a reason not to. A bigger machine is a one-line change and a fleet is a project, and real companies and interviews reward that reasoning equally.
Two reasons force your hand. Redundancy, when downtime stops being acceptable, and the ceiling, when the biggest machine available is no longer enough. Cost sometimes forces it too, since several medium instances often undercut one enormous one.
Answer by tier, not by philosophy
Split your answer by tier rather than picking a philosophy. Your stateless application tier goes horizontal almost immediately, and not for capacity: two small instances behind a balancer buy you deploys and failure tolerance for very little money.
Say that, then say your sessions live in a shared store so the machines stay interchangeable, and you have answered the follow-up before it arrives.
Give your database the opposite instinct. Scale it up, add copies for read traffic, and add caching. Reach for sharding only when sustained writes genuinely exceed what one primary can take, which for a tuned relational database is thousands a second.
Avoid the classic flag. Jumping straight to a sharded database for a system doing 50 writes a second is overengineering, and interviewers watch for it.
Do the arithmetic out loud. If you need 2,000 requests a second and one application server handles 400, that is five servers plus headroom, so call it eight. Numbers like that, even rough ones, separate people who have run systems from people who have read about them.
Close by naming the cost you accepted. Horizontal buys capacity and availability, and the bill is distributed complexity, from managing configuration to the consistency questions the rest of this course exists to answer.
Worked example
Elena gets the classic prompt: design an image sharing service for 5 million daily users. She starts with math: maybe 10 reads per user per day, call it 600 requests per second average and 2,000 at peak. App tier: stateless, 3 instances behind an ALB for availability, autoscaling for spikes. Database: one Postgres primary handles the roughly 60 writes per second easily, so she adds one read replica for the read-heavy feed and stops there. The interviewer pushes: what about 50x growth? Only then does she bring in a CDN for images, more replicas, and sharding by user ID. The feedback afterward says exactly what she wanted: scaled in response to numbers, not by reflex.