Practice
1. A distributed database requires that every write is confirmed by a majority of replicas before acknowledging success to the client. Which replication strategy best fits this requirement?
easy
Solution
Step 1: Identify replication strategy matching majority confirmation
Synchronous replication with quorum writes requires majority replicas to acknowledge before success.Step 2: Eliminate asynchronous and single-leader without ack
Asynchronous replication and single-leader without acknowledgments do not guarantee majority confirmation before success.Final Answer:
Option C -> Option CQuick Check:
Quorum writes ensure majority ack before success [check]
Hint: Quorum writes wait for majority acks before success [OK]
Common Mistakes:
2. In a fraud detection system ingesting thousands of transactions per second, which component is best suited to decouple the high-throughput transaction ingestion from downstream real-time scoring to avoid backpressure?
easy
Solution
Step 1: Identify decoupling mechanism
Relational DB batch inserts (A) add latency and don't handle high write throughput well. Redis (C) lacks durability guarantees for buffering. Direct synchronous calls (D) cause backpressure and tight coupling.Step 2: Evaluate Kafka suitability
Kafka supports high-throughput, partitioned by user ID to maintain ordering per user, and durable storage, enabling asynchronous processing and backpressure handling.Final Answer:
Option D -> Option DQuick Check:
Kafka partitions decouple ingestion and scoring with durability and ordering [check]
Hint: Kafka partitions buffer high-throughput streams reliably [check]
Common Mistakes:
3. A web API needs to enforce a rate limit of 100 requests per minute per user, allowing bursts but avoiding sudden resets at minute boundaries. Which rate limiting approach best fits this requirement?
easy
Solution
Step 1: Identify burst tolerance and smooth rate enforcement
Fixed window counters reset abruptly at minute boundaries, causing spikes. Token and leaky buckets enforce steady rates but may not track exact recent usage.Step 2: Sliding window counters track requests continuously over the last 60 seconds, allowing bursts without sudden resets
Sliding window counters provide smoother rate limiting by considering recent activity, avoiding boundary effects.Final Answer:
Option B -> Option BQuick Check:
Sliding window smooths rate limits over time, avoiding fixed window spikes [check]
Hint: Sliding window smooths counts over time, fixed resets abruptly [check]
Common Mistakes:
4. If the idempotency key store becomes unavailable, what is the most likely failure mode for the payment API when a client retries a payment request?
medium
Solution
Step 1: Understand idempotency store role in retries
Without the store, the API cannot verify if a request is a retry, so it must delay processing to avoid duplicates.Step 2: Eliminate other options
Rejecting all requests is possible but not typical; processing retries as new causes duplicates, which is avoided; fallback caches are uncommon and inconsistent.Final Answer:
Option B -> Option BQuick Check:
Unavailable idempotency store causes request queuing to prevent duplicates [check]
Hint: No idempotency store -> queue retries to avoid duplicates [check]
Common Mistakes:
5. At 10x traffic scale, which CDN component is most likely to become the bottleneck first and why?
hard
Solution
Step 1: Analyze scaling characteristics of CDN components
Origin servers can be scaled horizontally; DNS is stateless and highly distributed; load balancers can be scaled or replaced.Step 2: Identify edge node bottleneck
Edge nodes have fixed cache storage and network bandwidth per PoP; scaling traffic 10x stresses these resources first.Final Answer:
Option B -> Option BQuick Check:
Edge nodes limited by cache and bandwidth -> bottleneck at 10x scale [check]
Hint: Edge nodes limited by cache and bandwidth first [check]
Common Mistakes: