TL;DR: Scale horizontally when state can be partitioned or requests served statelessly; scale vertically when consistency or legacy design makes distribution expensive. A relational primary whose hot set fits in memory on one large box is often cheaper, faster and far easier to operate than a sharded cluster doing the same job.
How to approach it
Define both in one line each, then immediately name the property that decides: can the workload be split without changing its semantics? Everything else is detail. Have a concrete vertical-wins example ready, because that is what separates an opinion from experience.
A strong answer
Horizontal scaling adds machines; vertical adds resources to one machine. Horizontal is the default for stateless tiers because adding capacity is a template change with no code. But it has a price that only shows up when state is involved: data must be partitioned, partitions must be rebalanced, cross-partition operations become distributed transactions, and every guarantee you were used to now carries asterisks.
Vertical wins when the workload resists splitting:
A single-writer relational primary. Postgres supports SERIALIZABLE isolation, but its default is READ COMMITTED; stronger isolation can add overhead and serialization failures requiring retries. Shard it and unique constraints, foreign keys and transactions across shards become engineering projects. If your write throughput fits comfortably on modern hardware, and it does more often than people expect: a current large instance offers on the order of 100-plus cores and several TB of RAM, so a hot working set of a few hundred GB is cache-resident and can avoid storage reads for that hot set; CPU, contention and write rate still need benchmarking.
Operational simplicity as a requirement. One primary plus one standby is understood by every on-call engineer. A twelve-shard cluster with a routing layer, rebalancer and scatter-gather query path is a product your team also has to maintain. For a team of five, the second system costs more than the bigger box.
Licensing and legacy constraints. Commercial databases licensed per socket, vendor software certified only at specific sizes, or a monolith whose data access patterns assume a local join universe. Rewriting for distribution can cost person-years to avoid hardware spend that should be priced against the actual provider and licensing contract.
Latency-sensitive locality. An in-memory cache or matching engine where every microsecond of network hop shows up in the p99. Keeping the whole working set on one machine, with threads and memory placed deliberately across its NUMA topology beats any cluster that must hop between nodes.
The honest framing is a sequence, not a binary: run vertically until the pain of the next box exceeds the pain of distribution, then split along the seam that is embarrassingly parallel first (reads via replicas, then stateless services) and shard the write path last. I reverse toward horizontal early when availability requirements dominate, since one machine is one blast radius no matter how large, or when growth is steep enough that the next box arrives before the team has digested the last migration.
What interviewers probe next
"What are the hard ceilings of vertical scaling?" Single-socket memory bandwidth and NUMA effects arrive before core counts do, failover still needs a second machine, and the largest instances carry the worst pricing per unit of compute. The ceiling is real but sits higher than most designs need.
"Doesn't vertical scaling mean downtime to upgrade?" On cloud providers, changing instance size means a stop or a live migration you do not control. Mitigate with replicas and planned failover, which is exactly the operational muscle a primary-standby pair already has.
"Where does this reasoning appear in real systems?" etcd, Kafka's partition leaders, and every managed database tier all cap single-node size for precisely these reasons, then force partitioning above the ceiling.
Common mistakes
Answering "horizontal" reflexively and being unable to name a cost of sharding. The question exists to find candidates who have actually operated a sharded system.
Treating vertical as obsolete because the cloud made machines fungible. Fungible machines did not repeal Little's law or ACID.
Forgetting availability entirely. Vertical versus horizontal is mostly about consistency and complexity trade-offs; the blast-radius argument against single boxes applies regardless.