AlignUp Logo

How to Approach System Design Interviews

10 min read

Why You Need a Framework

System design interviews are open-ended by nature. There's no single correct answer. What interviewers evaluate is your process — how you break down ambiguity, make trade-offs, and communicate your thinking.

Without a structured approach, most candidates either:

  • Jump straight to architecture — drawing boxes before understanding what to build
  • Get lost in details — spending 20 minutes on database schema while ignoring the big picture
  • Freeze up — not knowing where to start

A repeatable framework solves all three problems.

The 4-Step Framework

Every system design interview follows the same structure. Spend your time roughly as follows:

StepTimeWhat You Do
1. Requirements~5 minClarify what to build
2. High-Level Design~10 minCore components and data flow
3. Deep Dive~15 minScale, optimize, handle edge cases
4. Wrap Up~5 minTrade-offs, monitoring, future work

These time splits are approximate. The interviewer may spend more time on deep dives or ask you to skip ahead. Stay flexible.

Step 1: Clarify Requirements (5 minutes)

Never start designing before you know what you're building. Ask questions to nail down:

Functional Requirements

What does the system do? Define the core user actions:

  • "Users can upload photos and share them with followers"
  • "The system generates a shortened URL from a long URL"
  • "Users can send messages that are delivered in real-time"

Aim for 3-5 clear functional requirements. Write them down.

Non-Functional Requirements

How should the system behave? These constrain your design choices:

  • Scale — How many users? How many requests per second?
  • Latency — Does it need to be real-time? Sub-100ms?
  • Availability — Can we tolerate downtime? (Usually no.)
  • Consistency — Is eventual consistency acceptable?

Stating non-functional requirements shows the interviewer you think about real-world constraints, not just happy-path functionality. This is what separates senior from junior candidates.

Back-of-the-Envelope Estimation

Do quick math to understand the scale:

  • Storage: How much data per day/year?
  • Bandwidth: How many requests per second?
  • Memory: Can the working set fit in cache?

You don't need exact numbers — order of magnitude is enough.

Step 2: High-Level Design (10 minutes)

Now draw the big picture. Start with the simplest architecture that satisfies your requirements, then evolve it.

Start with Core Components

Every system has:

  1. Clients — Who's making requests?
  2. API Layer — What endpoints exist?
  3. Application Logic — What processing happens?
  4. Data Storage — Where does data live?

Draw these as boxes with arrows showing data flow. Don't add complexity yet.

Define the API

Sketch the key endpoints:

POST /api/urls        → Create short URL
GET  /api/urls/:code  → Redirect to long URL
GET  /api/urls/:code/stats → Get click analytics

This grounds the discussion in concrete interfaces.

Choose Your Data Store

Pick a database based on your access patterns:

  • Relational (PostgreSQL) — Strong consistency, complex queries, transactions
  • Key-Value (Redis, DynamoDB) — Simple lookups, high throughput, low latency
  • Document (MongoDB) — Flexible schema, nested data, moderate query complexity
  • Wide-Column (Cassandra) — High write throughput, time-series data, eventual consistency

Don't say "I'd use NoSQL because it scales better." That's a red flag. Every database choice involves trade-offs — explain which trade-off you're making and why it fits your requirements.

Step 3: Deep Dive (15 minutes)

This is where you differentiate yourself. The interviewer will push on specific areas. Common deep-dive topics:

Scaling

  • Horizontal scaling — Add more servers behind a load balancer
  • Database sharding — Partition data across multiple database instances
  • Caching — Add Redis/Memcached to reduce database load
  • CDN — Serve static content from edge locations

Reliability

  • Replication — Primary-replica setup for database failover
  • Circuit breakers — Prevent cascading failures between services
  • Retry with backoff — Handle transient failures gracefully
  • Health checks — Detect and remove unhealthy instances

Specific Algorithms

Depending on the problem, you may need to discuss:

  • Consistent hashing (for distributed caching)
  • Rate limiting algorithms (token bucket, sliding window)
  • Conflict resolution (CRDTs, last-write-wins)
  • Pub/sub patterns (for real-time features)

Step 4: Wrap Up (5 minutes)

Summarize your design and discuss:

  • Trade-offs you made — "I chose eventual consistency because strong consistency would add latency"
  • What you'd improve — "With more time, I'd add monitoring and alerting"
  • Bottlenecks — "The database could become a bottleneck at 100K writes/sec"
  • Monitoring — "I'd track p99 latency, error rates, and cache hit ratio"

Proactively discussing trade-offs and limitations shows maturity. No design is perfect — interviewers want to see that you understand the constraints of your own solution.

Common Mistakes

  1. Not asking questions — Designing in silence for 30 minutes
  2. Over-engineering — Adding microservices, Kafka, and Kubernetes for a simple CRUD app
  3. Ignoring scale — Designing a single-server solution for a system that needs to handle millions of users
  4. No trade-off discussion — Presenting your design as the only possible solution
  5. Skipping estimation — Not knowing if your design can handle the required load

What's Next

Now that you have the framework, apply it to specific problems. Each problem breakdown in this course follows this exact structure — requirements, high-level design, deep dive, and trade-offs.