Requirements (~5min)
Functional Requirements
Completions for “Users/Clients should be able to…”, e.g., for Twitter: post tweets, follow other users, and see tweets from users they follow. Keep the list targeted and prioritized (e.g., top 3) as your job is to develop a system that meets those requirements.
Non-Functional Requirements
Completions for “The system should be…”, e.g., for Twitter:
- Highly available, prioritizing availability over consistency.
- Scale to support 100M+ daily active users.
- Low latency, rendering feeds in under 200ms.
Consider these when coming up with non-functional requirements:
- CAP Theorem: Should your system prioritize consistency or availability?
- Environment Constrants: Running on mobile device with limited memory?
- Scalability: Does the system have bursty traffic? Scale reads or writes more?
- Latency: How long can users wait, especially on requests that require meaningful computation?
- Durability: A social network might tolerate data loss, but a banking system cannot.
- Security: Data protection, access control.
- Fault Tolerance: How well does the system need to handle failures, e.g., redundancy, failover, and recovery mechanisms.
- Compliance: Are there legal requirements the system needs to meet?
Capacity Estimation
You can always assume you’re dealing with a large, distributed system. Skip estimations until they feed in directly to the design, e.g., when designing a TopK system for trending topics in FB posts, estimating the number of topics feeds into whether the data structure is a single instance, e.g., a min-heap, or a sharded one across multiple instances.
Core Entities (~2min)
The entities that your API will exchange and your system will persist in a data
model, e.g., for Twitter: User, Tweet, and Follow. Start with a small list
and iterate as you go, e.g., add relevant fields for each entity during the
high-level design.
API or Interface (~5min)
For the API protocol, consider:
- REST (Representational State Transfer): Uses
GET,POST,PUT,DELETEto perform CRUD operations on resources. Default choice for most. - GraphQL: Allows clients to specify exactly what data they want to receive, avoiding over/under-fetching. Useful when there are diverse clients with different data needs.
- RPC (Remote Procedure Call): Action-oriented protocol (e.g., gRPC) that’s faster than REST. Useful for internal APIs when performance is critical.
- Web Sockets or Server-Sent Events: Useful for real-time features.
For the Twitter example, choosing REST with core entities as resources:
POST /v1/tweets
body {
"text": string
}
GET /v1/tweets/{tweetId} -> Tweet
POST /v1/follows
body: {
"followee_id": string
}
GET /v1/feed -> Tweet[]
… and the user is derived from the authentication token (not from user input).
Data Flow (~5min)
A simple high-level sequence of actions/processes that the system performs on inputs to produce the desired outputs. Useful if the system involves a long sequence of actions, e.g., for a web crawler,
- Fetch seed URLs
- Parse HTML
- Extract URLs
- Store data
- Repeat
High-Level Design (~15min)
Draw boxes and arrows of different components (e.g., servers, databases) of your system and how they interact. Note areas where you can add complexity (e.g., caches, message queues), but don’t layer it on at this stage. Be explicit about data flows and what state changes with each request.
Make your diagrams easier to follow by documenting what needs to change. For
example, no need to write down that the User table has a name, email, and
password hash, if that’s not relevant to the flow you’re designing for.
Deep Dives (~10min)
Time to harden your design by ensuring that it meets all your non-functional requirements, addressing edge cases, identifying and addressing bottlenecks, and improving the design based on interviewer feedback. For example, “rendering feeds in under 200ms” leads to a discussion on fanout-on-read vs. fanout-on-write, caching, etc.
References
- System Design Delivery Framework. www.hellointerview.com . Accessed May 31, 2026.