Why Your App Stops Working as It Gets Popular

Aditya Sharma — Tue, 28 Jul 2026 13:59:02 +0000

This is Part 1 of my "From One User to One Million" series, where we'll build an understanding of System Design by following a simple application as it grows from a single user to millions. Instead of memorising technologies, we'll learn why they exist by solving real problems as they appear.

Why Your App Stops Working as It Gets Popular

Imagine you've just finished building your first web application.

It could be a chat application, an online store, or simply a college project you've spent weeks working on. After countless hours of coding, debugging, and testing, you finally deploy it to the internet.

The first few users sign up, and everything works exactly as expected. The pages load quickly, requests are processed almost instantly, and the application feels responsive. As more people begin using it, your confidence grows. If the application works perfectly for a hundred users, handling a thousand shouldn't be very different.

Unfortunately, software doesn't scale that way.

An application that performs beautifully for a few hundred users can begin struggling when thousands of people try to use it at the same time. Pages become slower, login requests start timing out, and eventually the server reaches a point where it simply cannot keep up with the incoming traffic.

What surprises many beginners is that the code itself hasn't changed. The same application that worked perfectly yesterday is running today. The only difference is that far more people are trying to use it simultaneously.

This is the point where software development becomes something bigger than writing code.

This is where System Design begins.

What is System Design?

When people first hear the term System Design, they often imagine complicated architecture diagrams filled with load balancers, databases, caches, message queues, and microservices. While all of these are important, they are not where System Design starts.

System Design is simply the process of designing an application so that it continues to work reliably as the number of users, requests, and data continues to grow.

In other words, System Design is about growth.

Every successful application starts small. It begins with a single server, a single database, and only a handful of users. As the application becomes more popular, new problems begin to appear. Engineers solve those problems by improving the architecture, and those improvements eventually become the technologies we hear about today.

This is exactly how we'll approach this series.

Instead of memorising technologies one after another, we'll follow the journey of a single application as it grows from a small project into a platform serving millions of users. Every time our application encounters a new problem, we'll first understand why it happened before learning the technology that solves it.

By the end of this series, you won't just know what a cache or a load balancer does. More importantly, you'll understand why they exist in the first place.

Before We Talk About One Million Users, Let's Start With One

Before we can understand why applications struggle under heavy traffic, we first need to understand what happens when just one person visits a website.

From the user's perspective, everything feels simple.

You open your browser, type a website's address, and within a second the page appears on your screen.

Behind that one second, however, several different systems are already working together.

The browser cannot directly contact a website because it doesn't know where that website is located. The first step is to find the server hosting the website.

To do this, the browser contacts the Domain Name System (DNS).

You can think of DNS as the internet's contact list.

When you call one of your friends, you probably search for their name instead of remembering their phone number. Your phone quietly translates that name into a number before making the call.

DNS works in exactly the same way.

Instead of remembering an IP address like 142.250.183.78, you simply type a domain name such as google.com. DNS translates that human-friendly name into an address that computers understand.

Once the browser knows where the server is located, it sends an HTTP request asking for the resource you want.

For example, visiting the homepage of a website might simply send a request like this:

GET /

The server receives this request and begins processing it.

If the website is static, the server can immediately send back the required files.

Most modern applications, however, need information from a database before they can respond.

Imagine opening Instagram.

The server first needs to answer several questions.

Which accounts do you follow?

What are the latest posts from those accounts?

Which stories should appear first?

Have you already liked any of these posts?

All of this information is stored inside a database.

The server requests the necessary data, the database returns it, and the server prepares the final response before sending it back to your browser.

Finally, the browser renders everything into the page you see on your screen.

Although the entire process usually takes less than a second, multiple systems have already worked together to complete a single request.

A simplified version of that journey looks like this:

Browser
   │
   ▼
DNS
   │
   ▼
Server
   │
   ▼
Database
   │
   ▼
Server
   │
   ▼
Browser

At first glance, the architecture seems perfectly reasonable.

One browser sends one request.

One server processes it.

One database returns the required information.

The browser displays the result.

Everything works exactly as expected.

Now Change Just One Thing

So far, we've only talked about one user.

Now imagine that 100,000 people open your application at almost exactly the same moment.

Nothing about the request itself has changed.

Every browser still contacts DNS.

Every request still reaches the server.

Every server still communicates with the database.

The architecture is identical.

The only thing that has changed is the number of requests arriving at the same time.

Instead of processing one request, the server is now trying to process thousands of them simultaneously.

Every request competes for the same CPU, the same memory, the same network bandwidth, and often the same database connections.

Eventually, the server reaches a point where it simply cannot process incoming requests as quickly as they arrive.

Some users begin waiting.

Others receive timeout errors.

Pages that previously loaded instantly now take several seconds.

Eventually, the application starts feeling slow, even though the code hasn't changed at all.

This is one of the most important ideas in System Design.

Applications rarely fail because one request is difficult.

They fail because millions of simple requests arrive at the same time.

That single change completely transforms the problem.

Instead of asking, "How do I write this feature?", engineers begin asking, "How do I design this system so it can continue handling more users?"

That is the real purpose of System Design.

What's Next?

In this article, we focused on understanding what System Design is and followed the journey of a single request from the browser to the server and back again.

That journey forms the foundation of everything we'll learn next.

In the next part of this series, we'll take a closer look at the server itself.

We'll answer questions such as:

What actually is a server?
How does it process requests?
How many requests can one server handle?
What determines its limits?
Why can't we simply buy a bigger server forever?

Once we understand the limits of a single server, the need for technologies like load balancers, caching, and horizontal scaling will become completely natural.

And that's exactly how we'll continue this journey—from one user to one million.

DEV Community: Aditya Sharma

Why Your App Stops Working as It Gets Popular