Scenario / Horizontal scaling

Horizontal Scaling & Load Balancers - Practice Scenario

Real-time messaging app launching publicly. Organic growth with unpredictable spikes from social shares.

Run this scenario

Briefing

Horizontal scaling & caching

Horizontal scaling increases capacity by adding more instances of a service instead of making one machine larger.

Adding servers is useful only when traffic is distributed cleanly and the database is not still doing the same repeated work for every request.

Scaling compute is straightforward. The database is always the hard part.

  • Add a load balancer when more than one server should share traffic.
  • Use cache for repeated reads that would otherwise hit the database.
  • Scale compute and read offload together instead of treating them as separate fixes.

Contract

Uptime

99.5%

P95 latency

200ms

Budget

$500/mo

Traffic shape

Viral spike that ramps quickly and decays unevenly. Baseline 50 users; peak around 3,000 users over 48 hours.

Available components

Server

HTTP request handler Every web app needs at least one server. More servers let you handle more simultaneous requests before latency starts climbing.

Postgres

Primary data store Without a database, your app has no memory. Most dynamic requests eventually depend on it.

Redis

In-memory cache layer Popular pages, profiles, and product data often get requested again and again. Serving those from memory is much faster and cheaper.

LB

Load balancer If you run more than one server, something needs to decide where each request goes. That is the load balancer.

Rate limiter

Request throttle During abuse events, legitimate traffic competes with junk traffic for server capacity. Filtering noisy traffic at the edge protects the rest of the stack.

Common mistakes

  • Traffic spikes need pre-positioned headroom and fast offload paths.
  • Connection pools can fail before raw database capacity reaches 100%.
  • Rolling recovery preserves availability better than restarting the whole fleet.
  • Hot keys need jitter, request coalescing, and enough fallback capacity.

Interview adjacency

  • Design a social feed
  • Scale a web service
  • Design Twitter timeline reads