Interview questions

Interview questions (with the counter-questions you'll get)

Q1. What's the difference between vertical and horizontal scaling?

They're testing: clear definitions and trade-offs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Vertical scaling makes one machine bigger: more CPU, memory or disk. It's simple and needs no code changes, but it has a hard ceiling, gets expensive at the top, and is still a single point of failure. Horizontal scaling adds more machines behind a load balancer. It has almost no ceiling and survives failures, but needs stateless servers and more operational work.
3
4**Counter-questions:**
5- *"Which would you choose for a database?"* → Usually scale up first, plus read replicas, because splitting state is hard. Shard only when one machine can't hold the data or the writes.
6- *"Is vertical scaling ever the right long-term answer?"* → Yes, for many systems. A single well-tuned database on a large machine can serve a lot of traffic; if it meets the needs, simplicity wins.
7
8**Trap:** saying horizontal is always better.

Q2. Why do stateless servers matter for scaling?

They're testing: the link between state and scaling out.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A load balancer can send any request to any server only if no server holds per-user data the next request needs. Stateless servers can be added, removed, replaced and restarted freely, so autoscaling, deploys and failures don't lose anything. State moves to shared stores: sessions to Redis, data to the database, files to object storage, pending work to queues.
3
4**Counter-questions:**
5- *"Can't sticky sessions solve it?"* → They hide it. Load becomes uneven, scaling in is hard, and a dead server still loses its users' state.
6
7**Trap:** "stateless means the app has no data".

Q3. How would you prepare for a traffic spike you know is coming, like a big sale?

They're testing: practical capacity planning.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Estimate the peak from past events or marketing numbers, then size each tier with headroom. Scale ahead of time with scheduled scaling, because reactive autoscaling lags by the warm-up time. Warm caches, check database capacity and connection limits, and load-test at the expected peak beforehand. Add protections for surprises: rate limits, queues for non-critical work, and features that can be switched off (Chapters 25 and 29).
3
4**Counter-questions:**
5- *"What if the spike is bigger than you planned?"* → Reactive autoscaling as a safety net, rate limiting or a waiting room to protect the core path, and degrading optional features (Chapter 43).
6
7**Trap:** "autoscaling will handle it".

Q4. How does autoscaling work, and what can go wrong?

They're testing: depth beyond the buzzword.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A controller watches a metric (CPU, requests per server, queue length) and adjusts the server count to keep it near a target, between a minimum and maximum. Things that go wrong: new servers take minutes to warm up so it lags sudden spikes; thresholds too close together cause flapping; the wrong metric scales the wrong thing; and scaling the app tier can overload the database behind it.
3
4**Counter-questions:**
5- *"How do you stop flapping?"* → Use different thresholds for adding and removing, a cooldown after each change, and scale in more slowly than you scale out.
6- *"Which metric for queue workers?"* → Queue length or the age of the oldest message, not CPU.
7
8**Trap:** describing only "it adds servers when busy".

Q5. How do you scale a database?

They're testing: knowing the order of options.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Cheapest first. Fix slow queries and add indexes, cache repeated reads, scale the machine up, add read replicas for read-heavy load, and only then shard the data across databases. Also manage connections with a pooler, since many app servers can overwhelm the database with connections.
3
4**Counter-questions:**
5- *"Replicas didn't help. Why?"* → The load is mostly writes, or the app reads from the primary. Writes need scaling up or sharding (Chapters 14 and 15).
6
7**Trap:** jumping straight to sharding.

Q6. Why doesn't adding servers always make a system faster?

They're testing: bottleneck and Amdahl thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Because the bottleneck may be elsewhere, like the database, a cache, or a shared lock, and because the part of the work that can't be split limits the speed-up. Amdahl's law says if 10% of the work is serial, the best possible speed-up is 10 times, however many servers you add. More servers can even make things worse by adding coordination and more database connections.
3
4**Counter-questions:**
5- *"How would you find the serial part?"* → Profile and trace requests; look for shared locks, single-threaded components, global counters and hot database rows.
6
7**Trap:** "add servers until it's fast".

Q7. What's the difference between performance and scalability?

They're testing: vocabulary precision.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Performance is how fast the system is under a given load, often for one user. Scalability is how well it keeps that performance as load grows when you add resources. A fast system can scale badly if it relies on one machine or a shared bottleneck.
3
4**Counter-questions:**
5- *"How do you measure scalability?"* → Load-test at increasing traffic and watch latency percentiles and errors as you add servers. Ideally, double the servers handles double the traffic at the same latency.
6
7**Trap:** using the two words interchangeably.

Q8. How would you scale a service that has to be stateful, like WebSocket chat servers?

They're testing: handling real-world state.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Keep the connection on one server, but keep everything important outside it: messages in a database or log, presence in Redis, and a pub/sub layer so any server can deliver to any user (Chapter 21). Then servers can still be added, and when one dies, clients reconnect to another and catch up from the shared store.
3
4**Counter-questions:**
5- *"How do you remove a server without dropping users?"* → Drain it: stop sending new connections, ask clients to reconnect elsewhere gradually, then shut it down.
6
7**Trap:** "you can't scale stateful services".

Q9. How would you keep scaling costs under control?

They're testing: business awareness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Autoscale so you pay for peaks only during peaks. Use reserved or committed pricing for the steady baseline, spot machines for interruptible batch work, and right-size machines from measured usage. Reduce work per request with caching. And weigh engineering time: complexity has a cost too.
3
4**Counter-questions:**
5- *"When would you not use spot machines?"* → For anything that can't be interrupted safely, like a primary database, or a server holding long-lived connections.
6
7**Trap:** only talking about adding capacity.

Q10. What's the first thing you'd scale if your site suddenly gets 10 times the traffic?

They're testing: structured thinking under pressure.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** First find what's actually saturated: check latency, errors and resource usage per tier. Usually I'd scale out the stateless app tier quickly, but the database is often the real limit, so I'd protect it with caching, read replicas and connection limits, and shed or queue non-critical work. Rate limiting keeps the core path alive while capacity catches up.
3
4**Counter-questions:**
5- *"The database is at 100% CPU. Now what?"* → Find the top queries and fix or cache them, move reads to replicas, temporarily disable expensive features, and scale the machine up if possible.
6
7**Trap:** "add more app servers" without checking the bottleneck.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 6.1 What scaling means | Q7, Level 5 |
18| 6.2 Vertical scaling | Level 1A, Q1 |
19| 6.3 Horizontal scaling | Level 1A, Level 2.2, Q1, Q6 |
20| 6.4 Why stateless | Level 1A.4, Level 1B, Q2 |
21| 6.5 Where state goes | Level 1B, Level 5.1, Q2, Q8 |
22| 6.6 Autoscaling | Level 2.4, Level 3, Level 4, Level 5.4, Q3, Q4 |
23| 6.7 The database | Level 1A.1, Level 5.3, Q5, Q10 |
24| 6.8 Cost | Level 2.3, Q9 |
25| 6.9 Which to choose | Level 1A, Level 2.1, Q1, Q10 |
26
27---

6. Vertical vs Horizontal Scaling