System Design — Part 01

Introduction

System design is not about drawing a complicated architecture diagram. It is about understanding a problem, identifying the constraints and designing a system that can reliably solve that problem at the required scale.

        A good system design starts with the question:
        What problem are we actually trying to solve?
    

Before selecting a database, cache, message queue or cloud service, we need to understand the users, traffic, data, performance requirements and failure scenarios.

1. Start With Requirements

The first step in system design is converting a vague business requirement into something technical and measurable.

Functional Requirements

Functional requirements describe what the system must do.

01

Create

Users can create resources.

02

Read

Users can retrieve resources.

03

Update

Users can modify resources.

04

Delete

Users can remove resources.

Non-Functional Requirements

These describe how well the system should work.

Availability
Latency
Throughput
Scalability
Consistency
Security
Reliability
Maintainability

2. Understand the Traffic

A system serving 100 users has very different requirements from a system serving 100 million users.

Question	Why It Matters
How many users?	Determines the overall system scale.
Requests per second?	Helps determine server capacity.
Read or write heavy?	Influences database and caching strategy.
Peak traffic?	Determines scaling requirements.
Expected growth?	Prevents designing only for today's traffic.

Never design only around the current traffic. Think about the expected growth and peak load.

3. The Basic Architecture

A simple web application often starts with a client, application server and database.

┌───────────────┐ │ Browser │ │ / Client │ └───────┬───────┘ │ │ HTTP ▼ ┌───────────────┐ │ Application │ │ Server │ └───────┬───────┘ │ │ Query ▼ ┌───────────────┐ │ Database │ └───────────────┘

This architecture is simple, understandable and often enough for an early-stage application.

The important part of system design is knowing when this simple architecture is no longer sufficient.

4. Components of a Modern System

Load Balancer

Distributes incoming requests across application servers.

Application Server

Contains the business logic and API implementation.

Cache

Stores frequently accessed data for faster responses.

Database

Provides durable storage for application data.

Queue

Handles asynchronous work and smooths traffic spikes.

Object Storage

Stores files such as images, videos and documents.

5. Scaling the Application

Vertical Scaling

Increase the resources of a single server.

Small Server │ ▼ Bigger Server CPU ↑ RAM ↑ Storage ↑

Vertical scaling is simple, but eventually a single machine reaches physical or economic limits.

Horizontal Scaling

Add more servers and distribute traffic between them.

┌── Application Server 1 │ Load Balancer ───┼── Application Server 2 │ └── Application Server 3

Horizontal scaling improves capacity and can also improve availability because the system does not depend on one server.

6. Why Caching Matters

Databases are usually much slower than reading a small value from memory. If the same data is requested repeatedly, caching can significantly reduce database load.

Client │ ▼ Application │ ▼ Cache / \ HIT MISS │ │ ▼ ▼ Return Database │ ▼ Cache

Example

Imagine a popular blog post is requested 50,000 times per minute. Instead of querying the database 50,000 times, the application can cache the rendered or frequently accessed data.

7. Database Design

Choosing a database should come after understanding the data and access patterns.

SQL

Useful when relationships, transactions and structured data are important.

NoSQL

Useful for certain high-scale or flexible data models.

Cache

Useful for fast temporary access to frequently used data.

Important Questions

How much data will we store?
How frequently is it read?
How frequently is it written?
Do we need transactions?
What consistency level is required?
How will the database scale?

8. Synchronous vs Asynchronous Work

Not every operation needs to happen while the user is waiting for the HTTP response.

Synchronous

User │ ▼ API │ ▼ Process Work │ ▼ Response

Asynchronous

User │ ▼ API │ ▼ Queue ───────────────► Worker │ │ ▼ ▼ Response Heavy Work

Examples of asynchronous work include sending emails, generating reports, processing videos and resizing images.

9. A More Complete Architecture

┌───────────────┐ │ Browser │ └───────┬───────┘ │ ▼ ┌───────────────┐ │ Load Balancer │ └───────┬───────┘ │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Server 1│ │ Server 2│ │ Server 3│ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ └────────────────┼────────────────┘ ▼ ┌───────┐ │ Cache │ └───┬───┘ │ ▼ ┌───────┐ │ DB │ └───────┘ ┌───────────────┐ │ Queue │ └───────┬───────┘ ▼ Workers

This architecture introduces several independently scalable components. But adding components also adds complexity.

More components do not automatically mean better architecture. Every component should solve a real problem.

10. The Most Important Principle

Start Simple

A common mistake in system design is immediately adding every technology we know.

Kubernetes, Kafka, Redis, microservices, sharding and multiple databases may sound impressive, but they also introduce operational complexity.

        Design for the requirements you actually have.
        Scale the architecture when the requirements demand it.
    

Good System Design Is About Trade-offs

There is rarely one perfect architecture. Every decision usually trades one property for another.

Decision	Benefit	Cost
Caching	Lower latency	Stale data / invalidation
Replication	Availability	More infrastructure
Queue	Async processing	More moving parts
Microservices	Independent scaling	Operational complexity

11. Quick System Design Checklist

Define the functional requirements.
Define the non-functional requirements.
Estimate users and traffic.
Estimate storage requirements.
Identify read/write patterns.
Design the basic API.
Choose an appropriate database.
Identify caching opportunities.
Identify asynchronous operations.
Consider failures and recovery.
Consider security.
Consider future scaling.

Interactive System Test

This section demonstrates how a blog can contain interactive JavaScript directly inside the article.

Waiting for a system event...

Conclusion

System design starts with understanding the problem, not with choosing technologies.

Once the requirements and traffic are understood, we can gradually introduce components such as load balancers, caches, databases, queues and workers.

The goal is not to create the most complicated architecture. The goal is to create the simplest architecture that reliably satisfies the requirements and can evolve as the system grows.

Part 01 takeaway: Understand the requirements → estimate the scale → design the simplest architecture → identify bottlenecks → scale where needed.

Comments