When Horizontal Scaling Makes Things Worse

Adding application capacity increased pressure on an already constrained database. The account describes database-access changes before further scaling.

[Overview] System Overview

Adding application servers increased pressure on a database that was already the bottleneck.

More servers meant more database connections, amplifying the actual bottleneck.

[Context] Situation before

Response times degrading. Obvious solution: more servers.

[Diagnosis] The real problem

Database was the bottleneck. More app servers = more queries = more database contention = worse performance.

[Boundaries] Working constraints

OPERATIONAL

• Cannot change database configuration during peak hours

[Decisions] Key tradeoffs

REJECTED

Add more app servers

Horizontal scaling

Amplifies database bottleneck.

CHOSEN

Fix bottleneck first

Optimize database access, then scale

Remove bottleneck before adding capacity.

[Design] Architecture design

1. Fix N+1 queries. 2. Add caching. 3. Add read replicas. 4. Then scale app tier.

When More Servers Makes Things Worse

Adding servers amplifies database bottleneck

[Approach] Execution model

##### Implementation

The recorded sequence was query optimization, Redis caching, a read replica, then further application-tier scaling. The underlying measurement records are not included in this account.

[Results] Changes described

The account describes reducing pressure on the database before increasing application capacity again. It does not supply the load-test inputs, latency distribution or observation window needed to reproduce a numerical performance comparison.

[Anti-patterns] What could have gone wrong

##### More Servers

Each additional server makes things worse. Eventually database collapses.

[Applicability] Where this pattern applies

##### When Scaling Fails

Performance degrades with more capacity. Database CPU high. N+1 query patterns.