Bird
Raised Fist0

Clarifying Requirements - Functional vs Non-Functional Questions to Ask

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Write Frontend

User submits requirement

Requirement data is captured and sent to Kafka

Protocol:WebSocket
BeforeUser has requirement data ready to submit
AfterRequirement sent to Kafka Cluster for processing
Kafka Cluster

Publish requirement message

Kafka appends requirement to topic partition

Protocol:Kafka Publish
BeforeRequirement message received from Write Frontend
AfterRequirement durably stored in Kafka log
Storage DB (Cassandra)

Write requirement data

Cassandra stores requirement for durable persistence

Protocol:Cassandra Write
BeforeRequirement message available in Kafka
AfterRequirement persisted in Cassandra storage
Redis Cache

Cache requirement data

Redis stores recent requirement for fast retrieval

Protocol:Redis SET
BeforeRequirement persisted in Cassandra
AfterRequirement cached in Redis for quick reads
Read Frontend

User queries requirement

Read Frontend fetches requirement from Redis cache

Protocol:Redis GET
BeforeRequirement cached in Redis
AfterRequirement displayed to user from cache
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Write Frontend│
└───────┬───────┘
        │ WebSocket
        ▼
┌───────────────┐
│ Kafka Cluster │
└───────┬───────┘
        │ Kafka Publish
        ▼
┌───────────────────────┐
│ Storage DB (Cassandra)│
└───────┬───────────────┘
        │ Cassandra Write
        ▼
┌───────────────┐
│ Redis Cache   │
└───────┬───────┘
        │ Redis SET
        ▼
┌───────────────┐
│ Read Frontend │
└───────────────┘
Design Rationale

This architecture illustrates a clear separation of concerns for handling functional and non-functional requirements. The Write Frontend captures user input and sends it via WebSocket to the Kafka Cluster, which acts as a durable, ordered message queue. Kafka decouples the write path from storage, allowing asynchronous processing. The Storage DB (Cassandra) provides durable persistence optimized for high write throughput and availability. To optimize read latency, recent requirements are cached in Redis Cache. The Read Frontend queries Redis first for fast access, falling back to Cassandra if needed. This design balances durability, scalability, and low latency reads, ensuring functional requirements are reliably stored and quickly accessible while supporting non-functional needs like availability and responsiveness.

Primary Focus

✓

Practice

(1/5)
1. A public API needs to support multiple client versions simultaneously without breaking existing integrations. Which versioning strategy best isolates client requests to avoid accidental breaking changes?
easy
A. Use content negotiation with Accept header media types to specify version
B. Use a custom HTTP header like X-API-Version to specify the version
C. Embed the version number in the URL path, e.g., /v1/resource
D. Rely on query parameters like ?version=1 to indicate API version

Solution

  1. Step 1: Identify version isolation requirements

    Embedding version in the URL path clearly separates client requests by version, preventing accidental routing to incompatible handlers.

  2. Step 2: Evaluate alternatives

    Custom headers and content negotiation can be ignored or mishandled by intermediaries or caches, risking breaking changes. Query parameters are less explicit and can cause caching issues.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    URL versioning cleanly isolates versions in routing paths [check]
Hint: URL path versioning isolates clients cleanly [check]
Common Mistakes:
2. For a system with frequent feature toggles and multiple teams deploying daily, which approach best balances deployment speed and risk mitigation?
medium
A. Rely solely on Canary deployments without feature flags
B. Use Blue-Green deployment exclusively for all releases
C. Combine Feature Flags for gradual feature exposure with Canary deployments for version rollout
D. Use Rolling deployments with manual rollback procedures

Solution

  1. Step 1: Identify constraints

    Frequent deployments and multiple teams require fast, low-risk releases.

  2. Step 2: Evaluate options

    Blue-Green alone is heavy for frequent deploys; Canary alone lacks feature granularity; Rolling with manual rollback is slow and risky.

  3. Step 3: Combine Feature Flags and Canary

    Feature Flags enable gradual feature exposure; Canary controls version rollout risk.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Feature Flags + Canary balance speed and risk for frequent deploys [check]
Hint: Feature Flags + Canary = fast, safe multi-team deploys [OK]
Common Mistakes:
3. For storing feature metadata and versioning in the registry, which storage approach is best when the system requires strong consistency and auditability for compliance?
medium
A. Use a relational database with ACID transactions and audit logging
B. Use a cloud object store with versioned files and eventual consistency
C. Use a distributed log system like Kafka to append feature metadata changes
D. Use a distributed NoSQL store with eventual consistency and high availability

Solution

  1. Step 1: Identify compliance needs for strong consistency and auditability

    Compliance requires strict transactional guarantees and immutable audit trails.

  2. Step 2: Evaluate storage options

    NoSQL and object stores offer eventual consistency, risking stale reads. Kafka provides append-only logs but lacks transactional ACID guarantees for metadata queries. Relational DBs provide ACID transactions and built-in audit logging, ensuring compliance.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Relational DBs ensure ACID and audit logging for compliance [check]
Hint: Compliance needs ACID and audit logs -> relational DB [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 in Spotify's streaming architecture is most likely to fail first and why?
hard
A. The metadata database due to increased write contention on user playlists
B. The streaming servers because maintaining millions of concurrent WebSocket connections is stateful and hard to shard
C. The CDN edge caches due to limited storage capacity per region
D. The offline download manager due to device storage limits

Solution

  1. Step 1: Identify stateful bottlenecks at scale

    Streaming servers maintain WebSocket connections which are stateful and tied to server memory.

  2. Step 2: Evaluate scaling challenges

    Metadata DB (A) can be sharded; CDN caches (B) scale by adding regions; offline manager (D) limited by device, not server scale. Streaming servers (C) face connection limits and resharding complexity.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Stateful WebSocket servers fail first at 10x scale [check]
Hint: Stateful WebSocket servers bottleneck at scale [check]
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