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
45 min · senior
senior

You are designing a messaging platform for a startup with 50 million daily active users (DAU). The system must support real-time message delivery with P99 latency under 200ms, end-to-end encryption, and offline message delivery. The business requires strict data privacy compliance and high availability with minimal downtime.

Constraints
  • End-to-end encryption required for all messages
  • Offline message delivery with guaranteed eventual consistency
  • P99 message delivery latency under 200ms
  • System must handle 50M DAU with peak QPS of 1.5 million messages/sec
  • Data privacy compliance (e.g., GDPR) mandates data residency and audit logs
📋
Guided Steps
1/5
Step 1
Identify Functional vs Non-Functional Requirements
What are the key functional and non-functional requirements for this messaging system? How do they impact your design?
💡 Hint
Think about user-visible features vs system-level constraints like latency and compliance.
Key Decision
Separate functional requirements (message send, receive, sync) from non-functional (encryption, latency, compliance) to prioritize design trade-offs.
Interviewer Expectation
Mid: Lists functional and non-functional requirements. Senior: Explains how non-functional constraints like encryption and latency shape architecture choices.
⚠️Common Wrong Answer
Mixing functional and non-functional requirements leads to unclear priorities and design trade-offs.
Step 2
Design Data Storage and Partitioning Strategy
How will you store messages to support high throughput, low latency, and offline delivery? What partitioning key will you choose?
💡 Hint
Consider Cassandra for write-heavy workloads and partition keys that enable efficient range queries for sync.
Key Decision
Use Apache Cassandra with partition_key=conversation_id to ensure linear scalability and efficient cursor-based sync for offline delivery.
Interviewer Expectation
Mid: Names Cassandra for scalability. Senior: Explains why conversation_id is better than sender_id for partitioning to maintain message order and reduce cross-node queries.
⚠️Common Wrong Answer
Using sender_id as partition key causes out-of-order messages and inefficient sync across partitions.
Step 3
Choose Messaging and Delivery Mechanism
What messaging infrastructure will you use to handle real-time delivery and offline message queuing? How do you ensure ordering and reliability?
💡 Hint
Kafka supports partitioned logs with ordering guarantees per partition and high throughput.
Key Decision
Use Apache Kafka with conversation_id as partition key to guarantee ordered message delivery and enable replay for offline clients.
Interviewer Expectation
Mid: Names Kafka for messaging. Senior: Explains how Kafka partitions by conversation_id ensure ordering and simplify delivery workers' logic.
⚠️Common Wrong Answer
Using RabbitMQ or generic queues without partitioning leads to unordered delivery and scaling bottlenecks.
Step 4
Design Encryption and Compliance Controls
How will you implement end-to-end encryption and ensure compliance with data residency and audit requirements?
💡 Hint
Consider client-side encryption with key management and audit logs stored in immutable storage like AWS S3 with versioning.
Key Decision
Implement client-side encryption with keys managed via AWS KMS and store audit logs in AWS S3 with versioning and lifecycle policies for compliance.
Interviewer Expectation
Mid: Mentions encryption and audit logs. Senior: Details client-side encryption benefits, key rotation, and immutable audit storage for GDPR compliance.
⚠️Common Wrong Answer
Server-side encryption only exposes plaintext to servers, violating end-to-end encryption requirements.
Step 5
Design Client Sync and Acknowledgement APIs
What APIs will you expose for clients to send messages, sync missed messages, and acknowledge receipt? How do these APIs support offline delivery and low latency?
💡 Hint
Design REST or gRPC endpoints with cursor-based sync and idempotent acknowledgements.
Key Decision
Expose SendMessage, SyncMessages, and AckMessage APIs with conversation_id and cursor tokens to enable efficient incremental sync and delivery guarantees.
Interviewer Expectation
Mid: Names basic endpoints. Senior: Explains cursor-based sync reduces data transfer and idempotent ACKs prevent duplicate processing.
⚠️Common Wrong Answer
Using simple polling APIs causes excessive load and high latency at 50M DAU.
🔌
API Design Challenge
Sketch 3 core API endpoints for the messaging system that cover sending a message, syncing messages after offline periods, and acknowledging message receipt.
Hints
  • How does the client send a message securely and efficiently?
  • How does the client sync missed messages after reconnecting?
  • How does the recipient acknowledge message receipt to ensure delivery guarantees?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Clear distinction and impact analysis of functional vs non-functional requirements
  • Use of Cassandra with conversation_id partition key for message storage
  • Use of Kafka with conversation_id partition key for ordered message delivery
  • Client-side end-to-end encryption with proper key management
  • Cursor-based sync and idempotent acknowledgement APIs
Good to Have - 30%
  • Immutable audit logs stored in AWS S3 for compliance
  • Heartbeat tracking with Redis TTL for online/offline detection
  • Use of gRPC for low-latency communication
Bonus - 10%
  • Discussion of key rotation and encryption key lifecycle management
  • Consideration of multi-region data residency constraints
Anti-patterns to Avoid
Using sender_id as partition key causes cross-partition queries and out-of-order delivery, leading to inefficient sync and increased latency
Relying on HTTP polling for message sync at 50M DAU results in 50 million reconnects per minute just to check for messages, collapsing under load and causing latency spikes
Server-side encryption only exposes plaintext to servers, violating end-to-end encryption requirements and risking data breaches
Using generic message queues without partitioning causes unordered delivery and scaling bottlenecks, reducing system reliability
Storing audit logs in mutable databases risks tampering and non-compliance with GDPR, compromising data integrity
Ignoring offline delivery leads to message loss or inconsistent user experience, reducing user trust and engagement
✅
Model Answer
▼ Reveal

Design a messaging system for 50M DAU with end-to-end encryption, offline delivery, and P99 latency under 200ms by leveraging Cassandra for storage, Kafka for messaging, and client-side encryption with compliance-focused audit logging.

Key Decisions
  • Use conversation_id as partition key in Cassandra and Kafka to maintain message order and enable efficient offline sync
  • Implement client-side encryption to ensure messages remain encrypted end-to-end, with AWS KMS managing key lifecycle and rotation
  • Design cursor-based SyncMessages API to allow clients to fetch only missed messages after offline periods, reducing bandwidth and latency
  • Use idempotent AckMessage API to confirm message receipt and enable exactly-once delivery semantics
  • Store audit logs in AWS S3 with versioning to meet GDPR compliance and ensure immutable traceability
  • Employ gRPC for low-latency communication to meet P99 latency requirements under high load
  • Use Redis with TTL-based heartbeats to optimize delivery by tracking client online/offline status
  • Apache Cassandra with partition_key=conversation_id for scalable, ordered message storage and efficient offline sync
  • Apache Kafka with conversation_id as partition key to guarantee ordered, high-throughput message delivery and replay
  • Client-side end-to-end encryption with AWS KMS for key management to meet privacy and compliance requirements
  • AWS S3 with versioned immutable audit logs for GDPR-compliant data residency and traceability
  • Cursor-based SyncMessages API enabling clients to fetch only missed messages after offline periods
  • Idempotent AckMessage API to confirm delivery and enable exactly-once processing semantics
  • Use of gRPC for low-latency, efficient client-server communication supporting P99 < 200ms
  • Heartbeat mechanism stored in Redis with TTL to track online/offline status for delivery optimization

Practice

(1/5)
1. A webhook delivery system must guarantee ordered delivery of events per subscriber, even under retries and failures. Which component is best suited to enforce per-subscriber ordering?
easy
A. A partitioned message queue like Kafka keyed by subscriber ID
B. A distributed cache like Redis to store last delivered event per subscriber
C. A relational database with a global sequence number column
D. A load balancer that routes events to the same delivery worker

Solution

  1. Step 1: Identify ordering guarantee mechanism

    Kafka partitions keyed by subscriber ID ensure all events for that subscriber go to the same partition, preserving order.

  2. Step 2: Eliminate other options

    Redis cache lacks strong ordering guarantees under retries; relational DB global sequence causes contention and latency; load balancer routing alone doesn't guarantee ordering without stateful processing.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka partition key -> per-subscriber ordering guaranteed [check]
Hint: Partition by subscriber ID for ordering [check]
Common Mistakes:
2. A video streaming service needs to deliver personalized movie recommendations to millions of users with low latency. Which component is best suited to handle the real-time personalization computation at scale?
easy
A. A distributed in-memory cache with precomputed user profiles updated asynchronously
B. A relational database with complex SQL queries for each user request
C. A batch processing system that recomputes recommendations once per day
D. A CDN edge server that directly computes recommendations on user devices

Solution

  1. Step 1: Identify personalization latency requirements

    Real-time personalization requires low latency responses, which batch processing (A batch processing system that recomputes recommendations once per day) cannot provide.

  2. Step 2: Evaluate component suitability

    Relational DB (A relational database with complex SQL queries for each user request) is too slow for per-request complex queries at scale. CDN edge servers (A CDN edge server that directly computes recommendations on user devices) lack the data and compute power for personalization. Distributed in-memory cache (A distributed in-memory cache with precomputed user profiles updated asynchronously) supports fast lookups with asynchronously updated profiles, fitting the latency and scale needs.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    In-memory cache with async updates enables low-latency personalization [check]
Hint: Precompute profiles in cache for fast personalization [check]
Common Mistakes:
3. In a microservices architecture, a client request flows through API Gateway -> Auth Service -> Order Service -> Inventory Service. At step 3, the Order Service calls Inventory Service synchronously. What happens if Inventory Service is slow at step 3?
easy
A. Auth Service caches Inventory Service response to speed up future calls
B. Order Service queues the request asynchronously and immediately returns success to client
C. API Gateway retries the Inventory Service call automatically without client awareness
D. Order Service blocks the client request until Inventory Service responds or times out

Solution

  1. Step 1: Trace synchronous call behavior at step 3

    Order Service calls Inventory Service synchronously, so it waits for response before replying to client.

  2. Step 2: Analyze impact of slow Inventory Service

    Because of synchronous call, client request blocks until Inventory Service responds or times out; no immediate return or retries happen automatically.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Synchronous calls block caller until response or timeout [check]
Hint: Synchronous calls block caller until response or timeout [check]
Common Mistakes:
4. At 10x scale, which component of a distributed Count-Min Sketch system is most likely to fail first and why?
hard
A. The network bandwidth saturates due to large sketch state synchronization
B. The sketch arrays in memory overflow due to fixed size limits
C. The hash functions become slower, increasing latency linearly
D. The centralized coordinator bottlenecks due to serializing all update requests

Solution

  1. Step 1: Identify bottleneck in distributed updates

    Centralized coordinator serializes updates to maintain consistency, limiting throughput.

  2. Step 2: Analyze other components

    Network bandwidth and hash function speed scale better; sketch arrays have fixed size but don't overflow.

  3. Step 3: Understand scale impact

    At 10x scale, coordinator becomes overwhelmed, causing update latency and failures.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Central coordinator serialization bottlenecks updates at scale [check]
Hint: Central coordinator serializes updates, bottlenecking at scale [check]
Common Mistakes:
5. At 10x transaction volume, which component in the digital wallet system is most likely to become the first bottleneck, and why?
hard
A. The event log (Kafka), because partition count limits throughput and rebalancing partitions causes downtime
B. The reconciliation service, because it performs expensive cross-checks on all transactions synchronously
C. The API gateway, because it handles all client requests and cannot horizontally scale due to session affinity
D. The ledger database, because it requires strong consistency and cannot shard entries without breaking double-entry guarantees

Solution

  1. Step 1: Analyze ledger database constraints

    Ledger DB enforces strong consistency and atomic double-entry transactions, limiting sharding options.

  2. Step 2: Compare other components

    Reconciliation (A) can be scaled asynchronously; API gateway (C) can be scaled with stateless design; Kafka (D) scales with partitioning but ledger DB consistency is harder to scale.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Ledger DB consistency limits sharding -> first bottleneck [check]
Hint: Ledger DB consistency limits sharding -> first bottleneck [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