Skip to main content

System design guide

System design for non-engineers

System design is how engineers plan complex software architectures. You do not need to design systems — but understanding the concepts helps you work with engineers, scope features, and make better product decisions.

Why non-engineers need system design vocabulary

When an engineer says “this feature would require significant backend work because of how we handle state”, do you know what they mean? System design vocabulary lets you have real conversations with engineers, understand trade-offs, and make better decisions about what to build.

Frontend vs Backend vs Database

The three-tier model is how most web applications are structured. Most web features touch all three layers — which is why engineering estimates often seem larger than expected.

Frontend

What users see

What users see and interact with. Browser or mobile app. HTML, CSS, JavaScript (React, Next.js).

Backend (server)

Business logic

Business logic. Processes requests, applies rules, talks to the database. Python, Node.js, Go, Java.

Database

Persistent storage

Persistent storage. Where data lives between sessions. PostgreSQL, MySQL, MongoDB.

Scalability basics

What happens when 10x more users try to use your product at once? That is a scalability question.

Vertical scaling

Make the server bigger (more RAM, faster CPU). Simple but has a ceiling.

Horizontal scaling

Add more servers. More complex but can scale to any size.

Load balancer

Distributes traffic across multiple servers so no single server gets overwhelmed.

Cache

Stores computed results so the system does not need to recalculate them every time. Redis is common.

Reliability and availability

Reliability is about building systems that keep working even when individual components fail. These terms appear in engineering reviews, incident post-mortems, and vendor contracts.

Uptime / SLA

A 99.9% uptime SLA means ~8.7 hours of downtime per year is acceptable.

Single point of failure

A component that, if it fails, takes down the whole system. Good system design eliminates these.

Redundancy

Having backup systems that take over if the primary fails.

Failover

Automatically switching to a backup system when the primary fails.

Microservices vs Monolith

Most startups start monolithic. Most large tech companies have moved to microservices. If engineering says “we need to break this out into a separate service”, this is the context.

Monolith

One large codebase that runs as a single unit. Simpler to start with, harder to scale.

Microservices

Small, independent services that each do one thing. More complex to build, easier to scale and deploy independently.

Terms you will hear in engineering discussions

Four terms that come up in sprint planning, architecture reviews, and incident post-mortems.

Latency

How long a request takes. Milliseconds matter for user experience.

Throughput

How many requests the system can handle per second.

Bottleneck

The component that limits overall system performance. Usually the database or a slow API call.

Rate limiting

Capping how many requests a user or client can make per period. Prevents abuse.

Next step

Learn how to work with engineers

System design vocabulary is the foundation. The tech communication guide covers how to apply it in real engineering conversations.

Tech communication guide