Bird
Raised Fist0

Clarifying Requirements - Functional vs Non-Functional Questions to Ask

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Clarifying Requirements - Functional vs Non-Functional Questions to Ask
Master the art of clarifying functional and non-functional requirements with probing questions to ace HLD interviews.
mediumSystem Design Interview ApproachFreq: high
⚙️
Functional Requirements
  • Define core user actions and workflows the system must support (e.g., message send, receive, delete).
  • Identify data entities and relationships (e.g., users, messages, conversations).
  • Specify system behavior under normal and edge cases (e.g., message ordering, retries).
  • Determine integration points with external systems or APIs.
  • Clarify user roles and permissions impacting functionality.
  • Establish expected data consistency and correctness guarantees.
📊
Non-Functional Requirements
  • Scale: Support 2 billion daily active users (DAU) with 40 messages per user per day.
  • Latency: 100ms P99 end-to-end message delivery time.
  • Availability: 99.99% uptime SLA to ensure minimal downtime.
  • Durability: Messages must be persisted with replication factor 3 for fault tolerance.
  • Security: Data encryption at rest and in transit with compliance to GDPR.
❓
Clarifying Questions to Ask
  • What are the primary user actions and workflows the system must support?
  • What are the expected peak and average traffic volumes (messages per second)?
  • What are the latency and availability SLAs for critical operations?
  • How long must data be retained and what are the backup requirements?
  • Are there any regulatory or compliance constraints impacting design?
  • What failure scenarios must the system gracefully handle?
Out of Scope
✗ Detailed UI/UX design and frontend implementation.
✗ Specific client SDK implementations or platform-specific features.
✗ Business logic for monetization or advertisement integration.
✗ Offline message caching on client devices.
📌
Assumptions
  • 2 billion DAU
  • 40 messages per user per day
  • 100 bytes average message size
  • Retention period of 30 days
  • Replication factor of 3 for durability
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 messages/sec
peak write qpsAssuming 3× peak factor: 925,926 × 3 ≈ 2.78M messages/sec
read qpsAssuming 2 reads per message: 925,926 × 40 × 2 / 86400 ≈ 1.85M reads/sec
💾
Storage Estimate
daily storage gb(2B × 40 × 100 bytes) / (1024^3) ≈ 7.45 TB/day
monthly storage gb7.45 TB × 30 ≈ 223.5 TB
with replication gb223.5 TB × 3 ≈ 670.5 TB
🖥️
Server Estimate
write frontendAssuming 10K writes/sec per server: 2.78M / 10K ≈ 278 servers
storage nodesAssuming 10 TB usable per node: 670.5 TB / 10 TB ≈ 67 nodes
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |   Clients   |
          +------+------+
                 |
          +------+-------+
          | Write Frontend|
          +------+-------+
                 |
          +------+-------+
          | Kafka Cluster|
          +------+-------+
                 |
          +------+-------+
          |  Storage DB  |
          +------+-------+
                 |
          +------+-------+
          | Read Frontend|
          +------+-------+
                 |
          +------+-------+
          |   Clients    |
🧩
Components
Write Frontend
Handles client write requests, performs validation, and publishes messages to Kafka.
Why thisStateless microservices scale horizontally to handle 2.78M peak writes/sec with load balancing using container orchestration like Kubernetes.
Why notMonolithic servers would bottleneck and complicate scaling at high QPS, lacking microservice benefits.
Kafka Cluster
Durable, distributed message queue to decouple writes from storage and enable asynchronous processing.
Why thisApache Kafka supports high throughput (millions of msgs/sec), partitioning, and replication for durability.
Why notRabbitMQ lacks Kafka’s throughput and partitioning scalability at 2.78M msgs/sec.
Storage DB (Cassandra)
Stores messages with high write throughput, horizontal scalability, and replication.
Why thisApache Cassandra’s write-optimized LSM storage and tunable consistency fit 925K+ writes/sec and 670TB data.
Why notPostgreSQL requires manual sharding and cannot sustain linear write scale at this volume.
Read Frontend
Serves read requests with caching and query optimization to meet 1.85M reads/sec and 100ms P99 latency.
Why thisStateless API servers with Redis caching reduce DB load and meet latency SLAs.
Why notDirect DB reads cause high latency and overload Cassandra at peak read QPS.
Redis Cache
Caches hot message data and metadata for sub-millisecond reads and TTL-based eviction.
Why thisRedis supports fast in-memory lookups with TTL to expire stale data without cron jobs.
Why notMemcached lacks native TTL expiration and persistence, risking stale cache data.
🔄
Data Flow
1
Clients → Write Frontend
Client sends message write request
Frontend validates and authenticates request
2
Write Frontend → Kafka Cluster
Publishes message to Kafka topic partition
Decouples write ingestion from storage for scalability
3
Kafka Cluster → Storage DB
Storage workers consume messages and persist to Cassandra
Ensures durable, replicated storage with eventual consistency
4
Clients → Read Frontend
Client requests message reads
Read frontend checks Redis cache first
5
Read Frontend → Redis Cache
Fetch cached messages or metadata
Reduces read latency and DB load
6
Read Frontend → Storage DB
Fallback to Cassandra if cache miss
Ensures data availability and consistency
7
Read Frontend → Clients
Returns requested messages
Meets 100ms P99 latency SLA

Practice

(1/5)
1. In the job application tracking flow, at step 5 the Application Processor updates the candidate's application status in the database. What happens if the database write at this step fails due to a transient network error?
easy
A. The Application Processor retries the write immediately, blocking the workflow until success
B. The Application Processor logs the failure and queues the update for asynchronous retry later
C. The Application Processor skips the update and marks the application as failed permanently
D. The Application Processor rolls back the entire application submission transaction

Solution

  1. Step 1: Understand failure handling at Application Processor

    Transient DB errors should not block user workflow or cause permanent failure.

  2. Step 2: Evaluate options

    Immediate retry blocking (A) hurts latency; skipping update (C) loses data; rolling back entire submission (D) is heavy-handed. Queuing for async retry (B) ensures eventual consistency without blocking.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Async retry decouples transient failures from user flow [check]
Hint: Async retry avoids blocking on transient DB errors [check]
Common Mistakes:
2. A video calling system must establish peer-to-peer connections between clients behind NATs and firewalls. Which component is primarily responsible for enabling this connectivity?
easy
A. STUN/TURN servers that assist in NAT traversal and relay when direct connection fails
B. Media Server that relays all media streams to bypass NAT restrictions
C. Signaling Server that encodes and decodes media streams for transmission
D. WebRTC client library that manages user authentication and session persistence

Solution

  1. Step 1: Identify NAT traversal role

    STUN/TURN servers help clients discover public IPs and relay media if direct peer-to-peer fails.

  2. Step 2: Eliminate other components

    Media Server relays media but is not primarily for NAT traversal; Signaling Server handles session negotiation, not media encoding; WebRTC client manages connection but relies on STUN/TURN for NAT traversal.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    STUN/TURN enable NAT traversal, essential for peer connectivity [check]
Hint: STUN/TURN servers enable NAT traversal and relay fallback [check]
Common Mistakes:
3. In the DNS resolution chain, at step 4 the recursive DNS server receives a referral response from the root server pointing to a TLD server. What state does the recursive server enter immediately after receiving this referral?
easy
A. It caches the referral to the TLD server and initiates a query to the TLD server
B. It discards the referral and retries querying the root server
C. It caches the IP address of the root server and returns it to the client
D. It forwards the referral directly to the client without caching

Solution

  1. Step 1: Understand recursive server behavior on referral

    When the recursive DNS server receives a referral from the root server, it caches the referral information (the TLD server's IP) and then queries the TLD server itself.

  2. Step 2: Eliminate incorrect states

    It does not cache the root server IP (already known), nor does it discard the referral or forward it directly to the client. The recursive server handles the full resolution chain transparently.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Recursive server caches referral and queries next server [check]
Hint: Recursive server caches referrals and queries next hop [check]
Common Mistakes:
4. For an API gateway that must limit requests to a steady rate and avoid sudden bursts, which rate limiting approach is best and why?
medium
A. Token bucket, because it allows bursts up to token capacity
B. Sliding window log, because it tracks exact timestamps but allows burst spikes
C. Leaky bucket, because it enforces a fixed output rate smoothing bursts
D. Fixed window counter, because it resets counts periodically allowing bursts

Solution

  1. Step 1: Analyze burst handling requirements

    The system must avoid sudden bursts and enforce steady rate.

  2. Step 2: Compare algorithms

    Token bucket allows bursts, fixed window counters reset counts causing bursts, sliding window logs allow spikes due to timestamp granularity.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Leaky bucket enforces steady output rate, smoothing bursts [check]
Hint: Leaky bucket smooths bursts; token bucket allows bursts [check]
Common Mistakes:
5. At 10x scale, which component is most likely to fail first in the ticketing system and why?
hard
A. Seat Locking Service, because distributed cache memory saturates with millions of concurrent locks
B. Payment gateway, because increased transactions cause API rate limits and latency spikes
C. Web servers, because HTTP request handling cannot be parallelized beyond CPU cores
D. Database, because relational DBs cannot shard seat availability data efficiently

Solution

  1. Step 1: Identify scaling bottlenecks

    Seat Locking Service uses distributed cache to hold locks with TTL, which consumes memory proportional to concurrent locks.

  2. Step 2: Analyze 10x scale impact

    Memory saturation in cache causes eviction or failures, breaking seat locking guarantees. Payment gateway and DB can be scaled horizontally or sharded; web servers scale with load balancers.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Distributed cache memory limits -> seat lock failures at scale [check]
Hint: Cache memory saturates first under massive concurrent locks [OK]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard