Amit

Design & Frontend Developer

MailGitHubLinkedInTwitterPeerlist iconPeerlistGoogle Drive iconResume

How would you scale your application if traffic increases 10x?

So you built an app. It works. Maybe 50 people use it. Life is good.

Then something happens. Maybe it goes viral on Twitter. Maybe you posted it on Reddit and people actually liked it. Suddenly 500 people are trying to use it at the same time and your server is on fire. The site takes 30 seconds to load. Then it just dies.

Congrats, you have a scaling problem. Also this is literally what interviewers mean when they ask "how would you handle increased traffic" in system design rounds.

Let me break down what actually happens and what you can do about it.

First, understand where the bottleneck is

Your app is slow. But why?

Is your server CPU maxed out? Is it running out of memory? Is the database taking forever to respond? Is it waiting on some external API?

You need to figure this out before randomly throwing solutions at it. Adding more servers won't help if your database is the bottleneck. Caching won't help if you're CPU bound.

Most of the time, for most apps, it's one of these:

  • Database queries are slow
  • You're doing too much computation on each request
  • You're running everything on one tiny server

Cool. Now let's fix each of these.

Vertical scaling: Just get a bigger server

The dumbest and sometimes smartest solution.

Your $5/month server has 1 CPU and 1GB RAM. Upgrade it to a $40/month server with 8 CPUs and 16GB RAM. Boom, you can handle way more traffic.

This is called vertical scaling. You're making the machine taller (more powerful), not wider (more machines).

Pros:

  • Dead simple
  • No code changes
  • Works immediately

Cons:

  • There's a ceiling. You can only get servers so big.
  • Gets expensive fast
  • Single point of failure. If that one beefy server dies, everything dies.

For a college project or early startup, this is honestly fine. Don't over-engineer. If a bigger server solves your problem, just do that.

Horizontal scaling: More servers

Okay so you've maxed out vertical scaling or you want redundancy. Time to go horizontal.

Instead of one big server, you run multiple smaller servers. Traffic gets distributed between them.

But now you have a problem. When a user makes a request, which server handles it? You need something to distribute the traffic. That's a load balancer.

Users → Load Balancer → Server 1
                     → Server 2
                     → Server 3

The load balancer sits in front and sends each request to one of your servers. If a server dies, the load balancer stops sending traffic to it. If you need more capacity, spin up another server.

AWS has Elastic Load Balancer. You can also use Nginx as a load balancer. Cloudflare does this too.

The catch: your app needs to be stateless. If Server 1 stores some user data in memory, and the next request goes to Server 2, that data is gone. So you need to store state externally — in a database or Redis or something.

Database is usually the bottleneck

Here's a dirty secret: for most apps, the servers are fine. The database is what's dying.

You have 10 servers all hitting the same database. The database can only handle so many connections and queries. It becomes the chokepoint.

A few ways to deal with this:

Read replicas. Most apps read way more than they write. So you create copies of your database. Writes go to the main database, reads go to the copies. Now your read capacity is multiplied.

Write → Primary DB → syncs to → Replica 1
                              → Replica 2
Read requests get distributed across replicas

Connection pooling. Instead of each request opening a new database connection (expensive), you maintain a pool of connections and reuse them. Most ORMs have this built in.

Database indexing. Not really a scaling solution but I see people miss this all the time. If you're querying SELECT * FROM users WHERE email = 'xyz' and email column isn't indexed, the database scans every single row. Add an index and it's instant. Free performance.

Caching: Stop doing the same work twice

You have a page that shows "top 10 posts this week." Every time someone visits, you query the database, do some sorting, calculate scores, render the result.

But the result is the same for everyone. And it probably doesn't change every second. So why compute it on every request?

Cache it.

First request: compute the result, store it in cache (Redis, Memcached, whatever), return it.

Next 1000 requests: just return from cache. Don't hit the database at all.

result = cache.get("top_posts")
if not result:
    result = expensive_database_query()
    cache.set("top_posts", result, expires=300)  # cache for 5 mins
return result

This is stupidly effective. A lot of high-traffic sites serve most requests entirely from cache. The database barely gets touched.

You can cache at multiple levels:

  • Application level (Redis)
  • HTTP level (CDN caches your pages)
  • Browser level (response headers telling browsers to cache)

CDN: Make static stuff fast

If you're serving images, CSS, JavaScript, videos — don't serve them from your server. Use a CDN.

A CDN (Content Delivery Network) copies your static files to servers all around the world. When someone in India requests your image, they get it from a server in India, not from your server in US-East-1.

Cloudflare, AWS CloudFront, Vercel, Netlify — they all do this. Most have free tiers.

This also protects your actual server. If 90% of requests are for static files and the CDN handles all of them, your server only deals with the real API requests.

Async processing: Don't make users wait

User signs up. You need to:

  • Create their account
  • Send welcome email
  • Generate profile image
  • Notify analytics
  • Add to mailing list

If you do all of this in the request, the user waits 10 seconds staring at a spinner. And if the email service is slow, your whole app feels slow.

Solution: do the minimum in the request, queue the rest.

def signup(request):
    user = create_user(request.data)  # do this now
    queue.add("send_welcome_email", user.id)  # do this later
    queue.add("generate_avatar", user.id)     # do this later
    return {"success": True}  # respond immediately

A separate worker process picks up tasks from the queue and handles them in the background. The user doesn't wait. Your request handlers stay fast.

Redis Queue, Celery, BullMQ, AWS SQS — lots of options here.

Microservices: Maybe don't

You've probably heard about microservices. Breaking your app into tiny independent services that communicate over the network.

Here's my honest take: for 10x traffic, you almost certainly don't need microservices. They add massive complexity — network calls, service discovery, distributed tracing, deployment orchestration. It's a lot.

Microservices solve organizational problems (big teams working independently) more than technical ones. If you're a small team or solo, a well-structured monolith can scale really far.

Instagram was serving 100+ million users on a Django monolith. You're probably fine.

Scale vertically, add caching, optimize your database, use a CDN. If you've done all that and you're still struggling, then maybe think about splitting services.

The actual interview answer

If someone asks you this in an interview, here's a solid structure:

  1. Ask clarifying questions. What's the current architecture? Where's the bottleneck? What's the traffic pattern (spiky or steady)?

  2. Start simple. Vertical scaling, caching, database optimization.

  3. Then go horizontal. Load balancer, multiple servers, read replicas.

  4. Mention CDN for static content.

  5. Talk about async processing for non-critical work.

  6. Discuss tradeoffs. Every solution has downsides. Show that you know them.

Don't jump straight to "let's use Kubernetes and microservices and event-driven architecture." That's a red flag. Good engineers solve problems with the simplest thing that works.

What to actually learn

If you want to get better at this stuff:

  • Deploy something real. A side project on a VPS or Railway or whatever. Experience the pain.
  • Learn basic SQL optimization. EXPLAIN ANALYZE your queries.
  • Set up Redis once. Cache something. See the difference.
  • Read about how real companies scale. The Netflix tech blog, Uber engineering, etc.

System design isn't magic. It's just patterns that people figured out because they had the same problems you'll have. Learn the patterns, understand the tradeoffs, apply them when needed.

Don't prematurely optimize. But know the tools so you're ready when things blow up.