Once your design has load balancers and caches, the interviewer moves to the data layer. How is data copied and split across machines? What consistency does the system promise? How do services talk to each other without waiting? This second set covers those trade-offs, plus rate limiting and the classic URL shortener.
How to practise: read each question and tap the option you think is correct. You will see right away whether you got it, along with a short explanation, and your score is tracked at the bottom of the screen. This set has 15 questions.
Topics covered in this set
- CAP theorem and PACELC
- Leader-follower and multi-leader replication
- Sharding, hotspots and consistent hashing
- Quorums, eventual consistency and SQL vs NoSQL
- Idempotency, message queues and pub/sub
- Rate limiting algorithms and URL shortener sizing
System Design MCQs with answers and explanations
Q1. According to the CAP theorem, what must a distributed database choose between when a network partition happens?
a) Consistency and availability
b) Reads and writes
c) Speed and cost
d) Replication and sharding
Q2. What does PACELC add to the CAP theorem?
a) Even when there is no partition, the system trades off latency against consistency
b) A requirement to use SQL
c) A rule that partitions never happen
d) A way to avoid replication
Q3. In leader-follower replication with asynchronous followers, a user updates their profile and immediately reloads the page from a follower but sees the old data. Which technique fixes this?
a) Turning off replication
b) Read-your-writes consistency, such as reading the user's own data from the leader for a short time after a write
c) Adding more followers
d) Sharding by user ID
Q4. What is the main challenge of multi-leader replication?
a) Only one region can accept writes
b) The same data can be changed on two leaders at once, so write conflicts must be resolved
c) Reads become impossible
d) It needs a single global lock for every write
Q5. A table of events is sharded by a timestamp-based key so that each shard holds one time range. What problem is likely?
a) Joins become faster
b) Shards cannot be backed up
c) All new writes go to the newest shard, creating a hotspot
d) Data can no longer be indexed
Q6. Keys are placed on servers with hash(key) mod N. The cluster grows from 4 to 5 servers. About what fraction of keys must move?
a) About 80%
b) About 20%
c) About 25%
d) About 50%
Q7. With consistent hashing and N servers, roughly what fraction of keys move when one server is added, and why are virtual nodes used?
a) All keys move; virtual nodes reduce memory
b) Half the keys move; virtual nodes encrypt the ring
c) No keys move; virtual nodes store backups
d) About 1/N of keys move; virtual nodes spread each server across many ring positions for a more even load
Q8. A leaderless store has N = 3 replicas, writes wait for W = 2 acknowledgements and reads query R = 2 replicas. Why does this give up-to-date reads in normal operation?
a) Because W + R > N, so every read set overlaps at least one replica that has the latest write
b) Because R equals W
c) Because N is odd
d) Because reads are cached
Q9. Which workload is the strongest reason to choose a relational SQL database?
a) Money transfers that must update several rows atomically with strict integrity rules
b) Storing a social graph traversed many hops deep
c) Caching session tokens
d) Storing large amounts of log data with no fixed schema
Q10. What does eventual consistency guarantee?
a) Every read returns the latest write
b) If no new updates are made, all replicas will converge to the same value after some time
c) Replicas are updated in a fixed order
d) Writes are never lost
Q11. A payment API call times out and the client retries it. How can the server make sure the customer is not charged twice?
a) Use a message queue
b) Increase the timeout
c) Require an idempotency key with each request and return the saved result if that key was already processed
d) Reject all retries
Q12. What is the key difference between a point-to-point message queue and a publish/subscribe topic?
a) Queues are always faster
b) Queues need HTTP while pub/sub needs TCP
c) Pub/sub cannot store messages
d) In a queue each message is processed by one consumer; in pub/sub every subscriber receives its own copy
Q13. Which rate limiting algorithm allows short bursts up to a set capacity while enforcing an average rate over time?
a) Leaky bucket with a queue size of zero
b) Token bucket
c) Fixed window counter
d) Round robin
Q14. A fixed window rate limiter allows 100 requests per minute. A client sends 100 requests at 12:00:59 and 100 more at 12:01:00. What happens?
a) The second batch is delayed by one minute
b) Only the first 100 are allowed
c) The client is blocked for an hour
d) All 200 are allowed, so 200 requests pass within about two seconds
Q15. A URL shortener uses 7-character codes made from Base62 characters (a–z, A–Z, 0–9). About how many unique codes are possible?
a) About 1 billion
b) About 62 million
c) About 56.8 billion
d) About 3.5 trillion
Quick revision notes
- CAP: during a partition, pick consistency or availability. PACELC adds that, the rest of the time, you trade latency against consistency.
- Async replicas lag; use read-your-writes for a user's own data.
- mod-N hashing moves most keys on resize; consistent hashing moves about 1/N.
- Quorum overlap needs W + R > N.
- Idempotency keys make retries safe; token bucket allows bursts; 62⁷ ≈ 3.5 trillion codes.
Frequently asked questions
Should a URL shortener use a 301 or 302 redirect?
A 301 is permanent, so browsers cache it and later clicks may never reach your server. A 302 is temporary, so every click comes to your server. If you want correct click counts, use 302.
Is NoSQL always more scalable than SQL?
No. SQL databases scale well with replicas, partitioning and managed services. Pick based on your data model, how much consistency you need and how you query the data, not on scale alone.
Kafka or RabbitMQ: which should I mention in interviews?
Kafka is a durable log you can replay, good for large event streams. RabbitMQ is a flexible message broker, good for task queues and routing. Whichever you name, explain why your design needs it.
Comments
Post a Comment