The first step in any system design problem is understanding what the system is supposed to do. This involves identifying the main actions users will perform and clarifying use cases. These requirements drive your entire design and ensure that it aligns with user needs.

For example:

In a Short URL service, the main use cases are:

• Shortening a URL.
• Redirecting users from a short URL to the original URL.

For Twitter, key use cases might include:

• Allowing users to post tweets.
• Enabling users to view a home feed of tweets.
• Supporting engagement through likes, retweets, and replies.

It’s important to prioritize the core functionalities that are critical to the problem. Avoid spending time on secondary features that don’t directly impact the system’s main goals. For instance:

• In a Short URL service, features like user authentication or detailed analytics are secondary.
• In Twitter, media uploads or advanced search are less critical than enabling basic tweeting and home feed functionality.

By clarifying use cases, you establish the "why" behind the system, providing a clear direction for subsequent steps.

After understanding what the system should do, shift your focus to how it should perform. Non-functional requirements define the system's operational needs, such as scalability, reliability, and performance. These requirements help you make informed decisions about architecture and technology.

Key non-functional requirements to consider in an interview:

• Scalability: What traffic or data volume should the system handle?
• Latency: What response times are acceptable?
• Availability: What level of uptime is required?
• Consistency: Does the system require strong consistency (e.g., financial transactions) or can it tolerate eventual consistency (e.g., social media feeds)?
• Reliability: How should the system handle failures? For instance, should it have failover mechanisms for server or data center outages?
• Security: While less common in general interviews, you might ask about requirements for authentication, encryption, or DDoS protection if the role demands it.

These non-functional requirements provide a framework for architectural decisions, ensuring the system is designed to meet real-world demands.

For example:

In a Short URL service, the main non-functional requirements might include:

• Scalability: Handle millions of URL shortening and redirection requests daily.
• Latency: Redirect users from a short URL to the original quickly.
• Availability: Maintain very high uptime, especially for redirection functionality.

For Twitter, key non-functional requirements might include:

• Scalability: Serve 500M daily active users and handle millions of tweets per minute.
• Latency: Load the first 10 tweets of a user's home feed quickly (within 500ms?).
• Consistency: Allow slight delays in tweet propagation across regions (eventual consistency is ok).

Once again prioritize the goals that are important to the system’s performance. Avoid over-optimizing for secondary goals that don't align with the system's primary use cases.