Practice
1. A client application needs to fetch deeply nested related data in a single request without multiple round-trips. Which API design approach best supports this requirement?
easy
Solution
Step 1: Identify nested data fetching needs
REST typically requires multiple calls or over-fetching to get nested data, causing inefficiency.Step 2: Recognize GraphQL's single query nested fetch
GraphQL allows clients to specify nested fields in one request, reducing round-trips and over-fetching.Final Answer:
Option A -> Option AQuick Check:
GraphQL single query fetches nested data efficiently [check]
Hint: GraphQL fetches nested data in one query [check]
Common Mistakes:
2. If the Gossip Protocol component fails to propagate membership updates, what is the most immediate failure observed in the key-value store?
medium
Solution
Step 1: Understand gossip failure impact
Without membership updates, nodes are unaware of failed nodes and continue routing requests to them.Step 2: Eliminate other failure modes
Vector clocks handle versioning, unrelated to gossip failure. Consistent hashing ring updates rely on membership info but do not fail immediately. Write blocking on quorum is unrelated to gossip propagation.Final Answer:
Option B -> Option BQuick Check:
Missing membership updates cause requests to failed nodes causing timeouts [check]
Hint: Gossip failure -> nodes unaware of failures, keep sending requests [OK]
Common Mistakes:
3. For handling concurrent seat bookings, which architecture better suits a high-traffic ticketing system requiring low latency and strong consistency?
medium
Solution
Step 1: Analyze concurrency and latency requirements
High traffic and low latency require minimizing blocking and centralized bottlenecks.Step 2: Evaluate architectures
Centralized DB serializable transactions cause contention and latency; message queue serialization adds delay; client-side locking is unreliable. Distributed cache with optimistic locking allows concurrent attempts with retries, balancing consistency and performance.Final Answer:
Option D -> Option DQuick Check:
Optimistic locking in distributed cache balances concurrency and consistency [check]
Hint: Optimistic locking + retry beats centralized locks under load [OK]
Common Mistakes:
4. For ranking answers in the feed, which approach is better given the need for real-time updates and complex ranking signals including user behavior and spam scores?
medium
Solution
Step 1: Evaluate batch vs real-time ranking
Batch (A) is too stale for real-time user behavior; heuristic (C) lacks adaptability; client-side (D) cannot access server-side signals securely.Step 2: Online feature store benefits
Online feature stores enable real-time scoring with fresh data and incremental model updates, supporting complex signals and spam detection.Final Answer:
Option D -> Option DQuick Check:
Online feature store supports real-time, complex ranking [check]
Hint: Real-time ranking needs online features, not stale batch [check]
Common Mistakes:
5. At 10x traffic scale, which API Gateway component is most likely to become the bottleneck first, and why?
hard
Solution
Step 1: Identify scaling challenges
Rate limiting often relies on centralized counters or stores (e.g., Redis) that become contention points under high request rates.Step 2: Eliminate other options
Backend microservices, because they cannot horizontally scale as easily as the gateway is incorrect as backend services typically scale horizontally. API Gateway routing logic, because routing tables grow exponentially with services is unlikely as routing tables are cached and optimized. Authentication service, because token validation is CPU-intensive and stateful is less likely as token validation is stateless and can be cached.Final Answer:
Option A -> Option AQuick Check:
Centralized rate limiting store bottlenecks first at scale [check]
Hint: Centralized counters bottleneck rate limiting at scale [check]
Common Mistakes: