Functional Requirements (HLD)

Functional vs Non-Functional: The Clear Distinction

This is the most tested concept in system design interviews. Get this wrong and your entire design will be misaligned.

Functional Requirements

WHAT the system does. These are the observable behaviors and features.

Functional requirements answer:
• What actions can users perform?
• What data does the system process?
• What outputs does the system produce?
• What are the business rules?

Examples:

• Users can create, read, update, and delete posts
• The system generates a shareable short URL
• Users can search products by name and category
• The system sends email notifications on order placement

Non-Functional Requirements

HOW the system behaves. These are quality attributes and constraints.

Non-functional requirements answer:
• How fast must it be? (latency)
• How reliable must it be? (availability)
• How much can it handle? (scalability)
• How safe is it? (security)

Examples:

• Page load time under 200ms
• 99.99% uptime SLA
• Support 10M concurrent users
• Data encrypted at rest and in transit

The Test: Can You Demo It?

A quick heuristic to distinguish the two:

IF you can DEMO the feature to a stakeholder → Functional
IF you can only MEASURE it with metrics → Non-Functional

Demo-able: "Users can upload a profile picture" → Functional
Measurable: "Upload completes in under 2 seconds" → Non-Functional

How to Identify Core Features

Use the User Journey Method to extract features:

1. Identify the PRIMARY user action
   → For Twitter: "Post a tweet"
   → For Uber: "Request a ride"
   → For Netflix: "Watch a video"

2. Identify SUPPORTING actions
   → What must exist for the primary action to work?
   → For Uber: "Set pickup location", "Choose ride type", "Pay"

3. Identify ENHANCING actions
   → What improves the experience?
   → For Uber: "Rate driver", "View trip history", "Split fare"

Feature Extraction Template

System	Primary Action	Supporting Features	Enhancing Features
URL Shortener	Create short URL	Redirect, view analytics	Custom aliases, QR codes
Twitter	Post tweet	Follow, timeline, search	Trends, moments, lists
Chat App	Send message	Create conversation, receive message	Read receipts, typing indicator
Ride Share	Request ride	Set location, match driver, pay	Rate, trip history, split fare

Core vs Extended Features

CORE (must design)
├── The primary use case
├── The supporting actions
└── Basic error handling

EXTENDED (mention but don't design)
├── Admin features
├── Advanced analytics
├── Third-party integrations
└── Edge cases

Writing Good Functional Requirements

Bad: "The system should be fast."
Good: "The system shall return search results in under 200ms for 95% of queries."

Bad: "Users can do lots of things."
Good: "Users can: (1) create posts up to 280 characters, (2) follow other users, (3) view a chronological timeline of followed users' posts."

Format:

[Actor] can [Action] [Object] [Constraint]

Examples:
• Users can upload profile pictures (max 5MB, JPG/PNG)
• Admins can ban users with a reason code
• The system shall generate reports daily at midnight UTC

Use Case Format

Use cases formalize how users interact with the system. In system design interviews, you don't need full UML diagrams — but you should articulate the key flows.

Anatomy of a Use Case

USE CASE: Create Short URL

Actor: Any user (authenticated or anonymous)

Preconditions:
• User has a valid long URL
• System is operational

Main Flow (Happy Path):
1. User submits long URL
2. System validates URL format
3. System checks for existing mapping
4. System generates unique short code
5. System stores mapping in database
6. System returns short URL to user

Alternative Flows:
• 3a: If URL already exists, return existing short URL
• 2a: If URL is invalid, return 400 Bad Request
• 4a: If short code collision, regenerate

Postconditions:
• Short URL is stored in database
• Short URL is accessible via redirect endpoint

User Stories Format

User stories are lighter-weight and great for quick interview articulation:

As a [ROLE], I want [FEATURE] so that [BENEFIT]

Acceptance Criteria:
• Given [CONTEXT], When [ACTION], Then [RESULT]

Real Example: URL Shortener User Stories

ID	User Story	Priority
US-1	As a user, I want to paste a long URL and get a short URL so that I can share it easily	P0
US-2	As a user, I want to click a short URL and be redirected to the original page	P0
US-3	As a user, I want to see how many times my short URL was clicked	P1
US-4	As a user, I want to create a custom alias for my short URL	P1
US-5	As a user, I want my short URL to expire after a set time	P2
US-6	As a user, I want to see click analytics (geo, referrer, device)	P2

Use Case Diagram (ASCII)

                    ┌─────────────────────┐
                    │   URL Shortener      │
                    │      System          │
                    │                      │
  ┌───────┐        │  ┌──────────────┐    │
  │ User  │───────▶│  │ Create URL   │    │
  └───────┘        │  └──────────────┘    │
       │           │                      │
       │           │  ┌──────────────┐    │
       ├──────────▶│  │  Redirect    │    │
       │           │  └──────────────┘    │
       │           │                      │
       │           │  ┌──────────────┐    │
       └──────────▶│  │View Analytics│    │
                    │  └──────────────┘    │
                    └─────────────────────┘

Event Storming for Functional Requirements

Another way to extract functional requirements is event storming:

DOMAIN EVENTS (what happens):
┌──────────────────┐
│ URL Created       │──▶ System stores mapping, generates short code
│ URL Accessed      │──▶ System redirects, increments counter
│ URL Deleted       │──▶ System removes mapping (if owner)
│ URL Expired       │──▶ System marks as inactive
│ Analytics Viewed  │──▶ System aggregates click data
└──────────────────┘

COMMANDS (what triggers events):
┌──────────────────┐
│ CreateShortUrl    │──▶ POST /urls
│ RedirectUrl       │──▶ GET /{shortCode}
│ DeleteUrl         │──▶ DELETE /urls/{id}
│ ViewAnalytics     │──▶ GET /urls/{id}/analytics
└──────────────────┘

When to Use Use Cases vs User Stories

Approach	When to Use
Use Cases	Complex flows with multiple actors, error handling, and alternative paths
User Stories	Quick articulation of features, prioritization, MVP scoping
Event Storming	Domain-heavy systems with complex business logic

Interview tip: Use user stories for initial feature listing, then expand the P0 story into a use case with happy path and error handling.

REST API Design Principles

After defining functional requirements, translate them into API contracts. This demonstrates concrete thinking and gives the interviewer something tangible to discuss.

HTTP Methods and CRUD Mapping

HTTP Method	CRUD Operation	Idempotent	Use Case
GET	Read	Yes	Retrieve data
POST	Create	No	Create new resource
PUT	Update (full)	Yes	Replace entire resource
PATCH	Update (partial)	Yes	Modify specific fields
DELETE	Delete	Yes	Remove resource

URL Shortener API Design

Functional Requirements to API Mapping:

FR1: Create short URL       → POST   /api/v1/urls
FR2: Redirect short URL     → GET    /{shortCode}
FR3: Get URL details        → GET    /api/v1/urls/{shortCode}
FR4: Delete short URL       → DELETE /api/v1/urls/{shortCode}
FR5: Get analytics          → GET    /api/v1/urls/{shortCode}/analytics

Detailed API Specifications

1. Create Short URL

POST /api/v1/urls
Content-Type: application/json

Request Body:
{
  "long_url": "https://www.example.com/very/long/path?with=params",
  "custom_alias": "my-link",           // optional
  "expires_at": "2026-12-31T23:59:59Z" // optional
}

Response (201 Created):
{
  "id": "url_abc123",
  "short_code": "aB3xK9",
  "short_url": "https://short.ly/aB3xK9",
  "long_url": "https://www.example.com/very/long/path?with=params",
  "created_at": "2026-08-16T10:30:00Z",
  "expires_at": "2026-12-31T23:59:59Z"
}

Error Response (400 Bad Request):
{
  "error": "INVALID_URL",
  "message": "The provided URL is not valid"
}

2. Redirect Short URL

GET /{shortCode}

Response (301 Moved Permanently):
Location: https://www.example.com/very/long/path?with=params

Note: Use 301 (permanent) for SEO and caching.
Use 302 (temporary) if you need to track every click.

3. Get URL Details

GET /api/v1/urls/{shortCode}

Response (200 OK):
{
  "id": "url_abc123",
  "short_code": "aB3xK9",
  "long_url": "https://www.example.com/very/long/path?with=params",
  "created_at": "2026-08-16T10:30:00Z",
  "click_count": 1523,
  "is_active": true
}

4. Delete Short URL

DELETE /api/v1/urls/{shortCode}
Authorization: Bearer <token>

Response (204 No Content)

5. Get Analytics

GET /api/v1/urls/{shortCode}/analytics?period=7d

Response (200 OK):
{
  "short_code": "aB3xK9",
  "total_clicks": 1523,
  "unique_visitors": 892,
  "clicks_by_date": [
    {"date": "2026-08-10", "clicks": 145},
    {"date": "2026-08-11", "clicks": 189},
    {"date": "2026-08-12", "clicks": 201}
  ],
  "top_referrers": [
    {"referrer": "twitter.com", "clicks": 423},
    {"referrer": "linkedin.com", "clicks": 312}
  ],
  "top_countries": [
    {"country": "US", "clicks": 634},
    {"country": "UK", "clicks": 289}
  ]
}

API Design Best Practices

1. VERSIONING
   Use path versioning: /api/v1/...
   Easy to maintain, clear to clients

2. NAMING
   Use plural nouns for resources: /urls, /users
   Use kebab-case for multi-word: /short-urls

3. PAGINATION
   For list endpoints:
   GET /api/v1/urls?page=1&limit=20

4. ERROR HANDLING
   Use consistent error format:
   {
     "error": "ERROR_CODE",
     "message": "Human readable message",
     "details": {} // optional
   }

5. STATUS CODES
   200 OK          - Successful read/update
   201 Created     - Successful create
   204 No Content  - Successful delete
   400 Bad Request - Invalid input
   401 Unauthorized - Missing auth
   404 Not Found   - Resource doesn't exist
   429 Too Many Requests - Rate limited
   500 Internal Server Error - Server fault

API-First Design Approach

In interviews, sketching the API first helps ground the discussion:

Step 1: List functional requirements
Step 2: Map each to an API endpoint
Step 3: Define request/response for each
Step 4: Discuss which are read-heavy vs write-heavy
Step 5: This informs database and caching design

Example insight:
"GET /{shortCode} is our most frequent endpoint (1B/day).
This is read-heavy, so I'll add a caching layer."

GraphQL Alternative

For complex data requirements, mention GraphQL as an option:

type Url {
  id: ID!
  shortCode: String!
  longUrl: String!
  clickCount: Int!
  createdAt: DateTime!
  analytics: Analytics
}

type Query {
  url(shortCode: String!): Url
  urls(page: Int, limit: Int): [Url!]
}

type Mutation {
  createUrl(longUrl: String!, customAlias: String): Url!
  deleteUrl(shortCode: String!): Boolean!
}

Interview tip: REST is usually sufficient for system design interviews. Mention GraphQL only if asked about flexible querying or frontend-driven data needs.