Functional requirements
Functional requirements are the verbs of your system: upload, search, pay, notify. They define scope and drive your API surface and data model.
How to capture functional requirements
- Actors — who uses the system (end user, admin, third-party API consumer)?
- Core flows — the three to five journeys that matter most for the interview.
- Data entities — users, posts, orders, sessions and how they relate.
- Explicit exclusions — what you will not build in this session.
For a URL shortener, functional requirements might be:
POST /api/v1/links
Content-Type: application/json
{ "long_url": "https://example.com/very/long/path", "custom_alias": "promo" }
→ 201 { "short_url": "https://sho.rt/promo", "expires_at": null }
GET /promo
→ 302 Location: https://example.com/very/long/path
The redirect endpoint is the hot path; creation is admin-facing and lower volume. Noting that distinction early shapes your scaling strategy.
Requirements → cloud components
Non-functional requirements
NFRs are constraints and quality attributes. They determine whether you need a cache, a queue, or a multi-region deployment.
| Aspect | Functional | Non-functional |
|---|---|---|
| Question | What does it do? | How well does it do it? |
| Example | User can shorten a URL | Redirect in < 100 ms p99 |
| Drives | APIs and data model | Architecture and infra choices |
| Test | Feature acceptance tests | Load tests, SLO dashboards |
Question
FunctionalWhat does it do?Non-functionalHow well does it do it?Example
FunctionalUser can shorten a URLNon-functionalRedirect in < 100 ms p99Drives
FunctionalAPIs and data modelNon-functionalArchitecture and infra choicesTest
FunctionalFeature acceptance testsNon-functionalLoad tests, SLO dashboards
Both types belong in your opening requirements block.
Common NFR categories
- Scale — DAU, QPS, storage growth per year.
- Latency — p50/p99 response times per endpoint.
- Availability — uptime target (99.9% ≈ 8.7 hours downtime/year).
- Consistency — can reads be stale? for how long?
- Durability — zero data loss or bounded loss acceptable?
- Security — auth model, encryption, compliance (PCI, GDPR).
- Cost — budget per million requests or per TB stored.
Translating NFRs into design decisions
Each NFR maps to a concrete architectural choice. Say the mapping aloud in the interview.
| NFR | Design implication |
|---|---|
| 10M reads/sec, 1K writes/sec | Aggressive caching, async writes |
| p99 < 50 ms globally | CDN + edge caching + regional deployments |
| 99.99% availability | Multi-AZ, health checks, no single point of failure |
| Strong consistency on balance | Single-leader DB or distributed consensus |
| 5-year retention, 1 PB storage | Object storage + lifecycle tiers, not one Postgres row |
10M reads/sec, 1K writes/sec
Design implicationAggressive caching, async writesp99 < 50 ms globally
Design implicationCDN + edge caching + regional deployments99.99% availability
Design implicationMulti-AZ, health checks, no single point of failureStrong consistency on balance
Design implicationSingle-leader DB or distributed consensus5-year retention, 1 PB storage
Design implicationObject storage + lifecycle tiers, not one Postgres row
Prioritising when requirements conflict
Real systems cannot maximise everything. CAP, cost, and complexity force choices.
Scenario: Social feed for 50M users
Must have: sub-second feed load, 99.9% uptime
Nice to have: real-time updates (< 1s), global consistency
Can defer: full-text search, analytics dashboard
When the interviewer says "design Twitter," resist building every feature. Ask which slice they care about — posting, timeline, or search — and lock scope before drawing boxes.
Writing requirements on the board
A compact template keeps you organised:
functional:
- create_post(text, media)
- follow_user(user_id)
- home_timeline(limit, cursor)
non_functional:
dau: 300_000_000
read_write_ratio: 100:1
latency_p99_ms: 200
availability: 99.95%
consistency: eventual_ok_for_timeline
out_of_scope:
- DMs, ads, moderation
Common mistakes
Requirements pitfalls
- Listing features without quantifying scale or latency.
- Assuming strong consistency everywhere when the product tolerates staleness.
- Forgetting write volume — read-heavy systems still have write spikes.
- Ignoring operational NFRs: deploy frequency, rollback time, observability.
- Not stating out-of-scope items, then running out of time.
Quick recall
Everything you need if you only revisit this box.
- Functional = what the system does; non-functional = how well (scale, latency, availability).
- Capture actors, core flows, entities, and explicit exclusions for functional scope.
- NFRs drive architecture: cache for read-heavy, queue for async, replicas for availability.
- Use MoSCoW or a YAML block to prioritise when requirements conflict.
- Ask about scale and consistency early — interviewers reward structured questions.
- Always note out-of-scope items to keep the session focused.
Test yourself
Answer these before moving on — recall is what makes it stick.