When developers first hear the term system design, we usually imagine massive infrastructure.

Distributed databases. Load balancers. Microservices. Message queues. Millions of concurrent users.

For a long time, I believed system design was a topic reserved for enterprise architects. I was wrong.

The moment you stop building isolated UI pages and start building complete products, you are doing system design. The scale changes. The core principles do not.

My First Mistake

When I first started studying system design, I approached it like a set of terms to memorize.

I watched tutorials. I read blogs. I memorized terminology.

I could recite concepts like:

• Horizontal vs. vertical scaling
• Database replication
• Load balancing algorithms
• Eventual consistency

The problem was simple: I understood the words. I did not understand the problems they solved.

The Day It Started Making Sense

Everything shifted when one of my deployed full-stack projects started slowing down under manual testing.

The codebase wasn't massive. But suddenly, I had to answer difficult performance questions:

• Why is this client query causing a database bottleneck?
• Why am I fetching the same relational state on every page transition?
• Why does modifying this schema break an unrelated feature?

Without realizing it, I had stepped into real system design. Not the theoretical interview version. The hands-on, practical version.

System Design Is About Tradeoffs

The biggest misconception is believing there is a single "correct" architecture. Every architecture has tradeoffs.

Consider a simple monolithic setup:

    [ Simple Monolith ]
             │
             ▼
┌─────────────────────────┐
│  ✔ Zero Network Latency │
│  ✔ Rapid Code Delivery  │
│  ✘ Shared Bottlenecks   │
└─────────────────────────┘

Now compare it to a distributed microservices setup:

  [ Distributed Services ]
             │
             ▼
┌─────────────────────────┐
│  ✔ Isolated Scaling     │
│  ✘ Network Overhead     │
│  ✘ High Infrastructure  │
└─────────────────────────┘

Every architectural decision you make resolves one problem while introducing another. The goal is to choose the tradeoffs you are willing to manage.

Visualizing Application Pipelines

Instead of looking at applications as a collection of pages, I began breaking them down into structured pipelines.

For example, when a user requests a dashboard:

  Client Request
        │
        ▼
[ Better Auth Check ] ── (Session Isolation)
        │
        ▼
[ Database Query ] ── (Typed Drizzle JOIN)
        │
        ▼
[ Redis Cache Layer ]
        │
        ▼
  JSON Response

My Personal Architectural Rules

Through building and breaking projects, I developed a few reliable engineering rules.

Rule #1: Optimize for Simplicity First

I used to write abstractions for code that might exist in the future. Now, I write code for the constraints that exist today.

// Avoid over-engineered abstractions:
interface DataFactory<T, K, V, X, Y> {
  resolve(k: K): Promise<Record<string, V>>;
}
 
// Prefer direct, intent-driven APIs:
interface UserRepository {
  getById(id: string): Promise<User | null>;
}

The second solution is always easier to maintain, review, and refactor.

Rule #2: Enforce Clean Boundary Layers

I separate applications into strict, predictable boundaries:

  UI Components  (Client Rendering)
        │
        ▼
  Server Actions (Data Validation via Zod)
        │
        ▼
  ORM Schema     (Drizzle Relational Queries)
        │
        ▼
     Database    (PostgreSQL Tables)

This clean separation gives you:

• Easier unit and integration testing.
• Predictable debugging paths when errors occur.
• Boring architecture.

And boring architecture is exactly what survives production.

Rule #3: Database Performance Is a Frontend Feature

I learned that frontend latency is almost always a database optimization problem. If your query is slow, your UI will feel sluggish regardless of your frontend framework.

Consider a simple user lookup query:

-- Without indexing: PostgreSQL performs a sequential scan O(N)
SELECT * FROM users WHERE email = 'hello@abdul.in';
 
-- With indexing: PostgreSQL performs a fast B-Tree index scan O(log N)
CREATE UNIQUE INDEX idx_users_email ON users(email);

Query Plan Insight: Without an index, the database is forced to read every single row in storage. Adding a unique B-Tree index reduces search complexity from linear to logarithmic, cutting lookup execution times from seconds to sub-milliseconds.

What Building Projects Actually Taught Me

Building products taught me that system design is not about memorizing cloud diagrams. It is about learning to ask the right questions:

• What happens if this external API call fails?
• Is my database connection pool protected against traffic spikes?
• Can another developer understand this state model in five minutes?
• What tradeoff am I accepting by introducing this package?

These questions matter far more than theoretical system design lectures.

The progression of a developer is natural:

1. You write functions.
2. You write components.
3. You build applications.
4. You design systems.

Ultimately, system design isn’t about scaling software to millions of users on day one. It is about building software that still makes complete sense to you six months later.