System Design Basics: How to Approach Any Design Problem

"Design a news feed" is a vague sentence. Does it serve ten users or ten million? Must a new post appear instantly, or is a minute of delay fine? System design is the skill of turning vague goals like that into concrete decisions you can defend, and it starts long before you pick a database.

What system design actually is

System design is deciding how the parts of a software system (clients, servers, databases, caches, queues) are arranged so that the whole meets its goals at the expected scale. There is rarely one correct answer. There are only designs that fit particular requirements, and each one gives something up. A design that is perfect for a hobby blog is wrong for a payments platform, and the reverse is also true.

That is why good designers talk about trade-offs constantly: speed versus consistency, cost versus availability, simplicity versus flexibility. If a design has no downsides in your explanation, you probably have not found them yet.

Functional vs non-functional requirements

Functional requirements describe what the system does: users can post, follow others, see a feed, receive notifications. Non-functional requirements (NFRs) describe how well it does it: how fast, how available, how consistent, how durable, how large. Beginners spend all their time on the first kind, but the second kind is what actually drives architecture.

Back-of-envelope estimation

Estimation is not about being exact. It is about knowing whether you need one server or a hundred, a single database or a sharded cluster. Use round numbers, write your assumptions down and state them out loud. A useful shortcut is that a day has about 86,400 seconds, which you can treat as roughly 100,000 for quick math.

Here is an example for a small social app. These are illustrative assumptions, chosen to practise the method.

Even this rough sheet is informative. About 1,700 requests per second at peak is manageable with a handful of ordinary servers, and text storage of a few hundred GB per year fits comfortably in a single database node at first. If photos or videos were involved, storage and bandwidth would dominate instead, and the design would change to include object storage and a CDN. A few orders of magnitude are worth remembering: reading from memory takes on the order of 100 nanoseconds, an SSD read on the order of 100 microseconds, a network round trip inside one data center around half a millisecond, and a trip across continents on the order of 100 milliseconds or more. These are rough figures, but they explain why caches and nearby regions matter.

A repeatable 5-step framework

When you face a blank whiteboard, a framework stops you from jumping to favourite tools. Follow these steps in order, and revisit earlier steps when something new appears.

1. Clarify requirements and scope. List functional features, then NFRs. Decide what is out of scope (for example, ignore analytics for now).
2. Estimate scale. Traffic per second, read to write ratio, storage per year, bandwidth. Note which number is the biggest constraint.
3. Define the API and data model. Write the key endpoints and the main entities with their relationships. This reveals access patterns that later drive database choice.
4. Draw the high-level design. Start with one simple path (client, server, database), then add components only where a requirement or estimate demands them.
5. Deep dive on bottlenecks and trade-offs. Pick the riskiest parts (hot data, single points of failure, consistency) and explain alternatives, what each costs, and why you chose one.

The standard building blocks

Most designs combine the same handful of components. Knowing what each one is for lets you recognise where it belongs. Each of these gets its own lesson in this tutorial.

 Clients (web, mobile)
          |
          v
 +-----------------+
 |  Load balancer  |
 +-----------------+
      |        |
      v        v
 +---------+ +---------+
 | App  #1 | | App  #2 |  (stateless)
 +---------+ +---------+
      |  |       |  |
      |  +---+---+  |
      |      |      |
      v      v      v
 +----------+  +-------+
 |  Cache   |  | Queue |--> Workers
 +----------+  +-------+
      |
      v
 +----------+
 | Database |
 +----------+

Common mistakes

• Jumping to tools before requirements. Saying "we will use Kafka and Cassandra" in the first minute. Symptom: you cannot justify the choice when asked what problem it solves, and you may over-engineer a system that needs one database.
• Skipping estimation. Symptom: you shard a database that would have fit on one machine, or you ignore a read rate that needs a cache.
• Ignoring failure modes. Drawing only the happy path. Ask what happens when each box dies, and where the single points of failure are.
• Designing for the maximum from day one. Planning for a billion users when you have a thousand adds cost and complexity. Design for the next order of magnitude and know how you would grow beyond it.
• Presenting one option as obviously right. Always name at least one alternative and what it would cost you.

How this shows up in interviews and real projects

In interviews, the framework above is essentially the expected structure of a good answer, and interviewers care more about your reasoning and trade-offs than a final diagram. At work, the same habits appear in design documents: a short list of requirements, rough numbers, a diagram and a section on alternatives considered. For a preparation plan, read the system design interview prep guide, and for the wider picture of interview loops see how to crack FAANG interviews.