DEV Community

Akarsh
Akarsh

Posted on

System Design Isn’t Just About Drawing Boxes

#architecture #backend #softwareengineering #systemdesign

You can write clean code.

You can build REST APIs.

You can work with SQL and backend.

But what happens when 10 users become 10 million users?

That's where System Design starts becoming important.

System Design is not about drawing a complicated architecture diagram.

It's about understanding how software should be designed to work reliably at scale.

The Problem

A simple application might look like this:

User
  ↓
Backend Server
  ↓
Database
Enter fullscreen mode Exit fullscreen mode

For a small application, this can work perfectly.

But imagine:

  • 1 million users
  • Thousands of requests per second
  • Large amounts of data
  • Users from different locations
  • Server failures
  • Database overload

Suddenly, our simple architecture starts having problems.

The real question becomes:

How do we design the system so it continues working as the number of users grows?

That's the core idea behind System Design.

A Simple Example

Imagine you're building a food delivery application.

Initially:

100 Users
    ↓
1 Server
    ↓
1 Database
Enter fullscreen mode Exit fullscreen mode

Everything looks fine.

But the application becomes popular.

Now:

1 Million Users
       ↓
     ???
       ↓
   Database
Enter fullscreen mode Exit fullscreen mode

One server may not be enough anymore.

The database may become overloaded.

Requests may become slow.

And if that single server crashes...

The entire application goes down.

System Design helps us solve these problems.

Why This Matters

When designing large systems, we usually care about a few important properties.

1. Scalability

Can the system handle more users and traffic?

For example:

1,000 users
     ↓
10,000 users
     ↓
1,000,000 users
Enter fullscreen mode Exit fullscreen mode

A scalable system should be able to grow without requiring a complete redesign.

2. Availability

Is the system available when users need it?

If one server crashes, we don't want:

Server Down
     ↓
Application Down
Enter fullscreen mode Exit fullscreen mode

Instead, we might have:

        Load Balancer
        /           \
   Server 1       Server 2
      ❌              ✅
                       ↓
                    Users
Enter fullscreen mode Exit fullscreen mode

The system can continue serving requests.

3. Reliability

Does the system consistently perform its job correctly?

For example, in a payment system:

Payment Request
       ↓
   Processing
       ↓
    Success
Enter fullscreen mode Exit fullscreen mode

We don't want the user to be charged twice because the system processed the same request twice.

Reliability is about designing systems that behave correctly even when things go wrong.

4. Latency

How long does it take to get a response?

For example:

Request → Server → Database → Response
              500 ms
Enter fullscreen mode Exit fullscreen mode

Lower latency generally means a faster experience for users.

5. Throughput

How much work can the system handle in a given amount of time?

For example:

1000 requests / second
Enter fullscreen mode Exit fullscreen mode

A system handling 10 requests per second has very different requirements from one handling 100,000 requests per second.

The Basic System Design Mindset

When you see a system design problem, don't immediately start drawing boxes.

Think about:

Users
  ↓
Requirements
  ↓
Traffic
  ↓
API
  ↓
Application
  ↓
Database
  ↓
Cache / Queue / Storage
  ↓
Monitoring
Enter fullscreen mode Exit fullscreen mode

Each layer exists for a reason.

The goal isn't to add technologies just because they're popular.

The goal is to understand:

What problem does each component solve?

Quick Tips

If you're starting System Design, focus on these concepts first:

  • Scalability
  • Availability
  • Reliability
  • Latency
  • Throughput
  • Load Balancing
  • Caching
  • Database Scaling
  • Message Queues
  • API Design

These concepts will appear again and again in real-world architectures.

Common Mistake

One of the biggest mistakes beginners make is learning System Design as a collection of diagrams.

For example:

Load Balancer
Redis
Kafka
Database
CDN
Enter fullscreen mode Exit fullscreen mode

and thinking:

"I know System Design now."

Not quite.

The important question is:

Why is Redis here?

Why do we need Kafka?

Why are there multiple servers?

Why can't we just use one database?

Understanding the reason behind each component is much more valuable than memorizing architectures.

Recommended Resource

A great way to learn System Design is to practice designing familiar applications.

Start with simple systems such as:

  • URL Shortener
  • Chat Application
  • Food Delivery Application
  • Notification System
  • E-Commerce Application

Try answering:

"What happens when the number of users becomes 100x larger?"

That question alone will teach you a lot about scalability.

Top comments (0)