Module 0 — Core Concepts

Functional vs Non-Functional Requirements

The "what" vs the "how well". Both are critical for system design success.

1The Car Analogy

💡 Simple Analogy
When buying a car, you have two types of needs:

Functional (What it does): Gets you from A to B, has 4 seats, trunk space, AC, radio.

Non-Functional (How well it does it): 0-60 in 5 seconds (performance), 50 MPG (efficiency), 5-star safety rating (reliability), comfortable seats (usability).

A car that "drives" isn't enough. HOW WELL it drives matters for customer satisfaction.

2Functional Requirements

Functional Requirements describe WHAT the system should do—the features, behaviors, and capabilities users expect. They answer: "Can the system do X?"

Examples for Twitter:

✓Users can create an account
✓Users can post tweets (280 chars)
✓Users can follow other users
✓Users can like and retweet
✓Users can see a timeline of tweets
✓Users can search for tweets/users
✓Users can send direct messages
✓Users can upload images/videos
Interview Tip

Always clarify functional requirements first! Ask: "What are the core features we must support? What can we deprioritize for this discussion?"

3Non-Functional Requirements

Non-Functional Requirements (NFRs) describe HOW WELL the system performs—quality attributes like speed, reliability, and security. They answer: "How fast? How reliable? How secure?"
⚡Performance
  • • Page load < 2 seconds
  • • API response < 100ms
  • • Support 10,000 concurrent users
📈Scalability
  • • Handle 10x traffic during peak
  • • Scale from 1M to 100M users
  • • Add capacity without downtime
🟢Availability
  • • 99.99% uptime (4 nines)
  • • No more than 52 minutes downtime/year
  • • Survive single data center failure
🛡️Reliability
  • • No data loss ever
  • • Messages delivered at least once
  • • Transactions are atomic
🔒Security
  • • All data encrypted at rest & transit
  • • Authentication required
  • • Rate limiting against abuse
🔧Maintainability
  • • Easy to deploy updates
  • • Clear monitoring & alerting
  • • Well-documented APIs

4Side-by-Side Comparison

AspectFunctionalNon-Functional
FocusWhat the system doesHow well it does it
Example"User can upload photo""Upload completes in <3 sec"
TestingDoes feature work? Yes/NoMeasured with metrics
SourceBusiness/Product teamsEngineering/Operations
ImpactUser featuresUser experience

5Real Example: URL Shortener

Functional Requirements

  • → Given a long URL, generate a short URL
  • → When user visits short URL, redirect to original
  • → Users can create custom short URLs
  • → URLs can have expiration dates
  • → Track click analytics

Non-Functional Requirements

  • → Redirect latency < 50ms
  • → 99.99% availability
  • → Handle 100K redirects/second
  • → Store 100 billion URLs
  • → Short URLs should be unpredictable (security)

6Interview Strategy

1
Ask about scale
"How many users? How many requests per second? How much data?"
2
Clarify availability needs
"What's the acceptable downtime? Is 99.9% enough or do we need 99.99%?"
3
Understand latency requirements
"What response time do users expect? Is this real-time or can it be eventual?"
4
Discuss consistency vs availability
"Is it okay if data is slightly stale? Or must reads always see latest writes?"

7Key Takeaways

1Functional requirements = features (WHAT). Non-functional = quality (HOW WELL).
2Both are equally important—a fast system with missing features is useless, and vice versa.
3NFRs drive architecture decisions: caching for performance, replication for availability.
4Always quantify NFRs: "fast" is vague, "<100ms p99 latency" is measurable.
5In interviews, ask about both before designing. It shows maturity.
6Trade-offs often exist between NFRs: higher consistency may mean lower availability.