Scaling up vs scaling out

Performance and scaling Junior Python 3.13+ PostgreSQL 17+ Reviewed 31 Oct 2026 By Best Latest Apps

Pick the fix

App servers are at 20% CPU; the single Postgres primary is at 95% CPU from reads. Next step?

OptionsFix slow queries and add read replicas or caching for the read loadAdd more app serversShard immediatelyMove to a bigger app server

Hint 1 of 1

Which tier is saturated?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Fix slow queries and add read replicas or caching for the read load

Correct. The bottleneck is database reads.

Scale the tier that is saturated. The primary is at 95% from reads, so fix the slow queries first, then move reads to replicas or a cache.

Why not the others?

B Add more app servers. They aren't the bottleneck; more of them adds DB load.
C Shard immediately. A big step before cheaper options.
D Move to a bigger app server. Wrong tier.

30-second answer

Vertical scaling is simplest: no code changes, no distribution problems, and modern machines are huge, so it's often right for databases until it isn't. Its limits are a hard ceiling, cost that rises steeply at the top, and one machine as a failure point. Horizontal scaling adds capacity and redundancy, but needs stateless services, a load balancer, and for data, replication or sharding with all its consistency trade-offs. Usually: scale stateless tiers out, scale the database up first, then add replicas, then shard.

Practise saying it · 30 s. No recording, just a timer

Up or out?

Say your answer out loud, then check which of these points you covered:

Vertical: simple, ceiling
Horizontal: stateless + LB
DB: up, replicas, then shard
Redundancy

Deep dive

Stateless app servers keep sessions and files elsewhere (Redis, object storage).

Read replicas scale reads; writes still go to one primary.

Sharding is a big step; exhaust indexing, caching and replicas first.

Horizontal scale also means redundancy across zones.

Common mistakes

Sharding early 'for scale'.
Local disk or in-memory sessions on app servers.
Assuming more servers fix a database bottleneck.

Senior take & follow-ups

Trade-offs of each, then the usual order: app out, DB up, replicas, shards.

Follow-up questions

Think of your answer first, then open the hint.

What makes a service horizontally scalable?
Show hint
No local state; any instance can serve any request.
When shard?
Show hint
When one primary can't take the write volume or data size.

Suggest a fix if something here is wrong or out of date.