Consistency models (strong, eventual) in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Strong Consistency

In a distributed database with strong consistency, what guarantee does the system provide when a client reads data after a write operation?

A The client always reads the most recent write, ensuring no stale data is returned.

B The client may read stale data if the write has not propagated to all replicas yet.

C The client reads data from a random replica without any ordering guarantees.

D The client reads data only from the primary node, ignoring replicas.

💡 Hint

Think about what 'strong consistency' means for read-after-write behavior.

Strong consistency ensures that once a write completes, all subsequent reads will see that write or a later one. This means no stale data is returned after a write.

🧠 Conceptual

intermediate

Eventual Consistency Behavior

In an eventually consistent system, what is true about the data read by clients immediately after a write operation?

A Clients always read the latest write immediately after it happens.

B Clients might read stale data temporarily, but all replicas will converge eventually.

C Clients cannot read data until all replicas confirm the write.

D Clients read data only from the replica that processed the write.

💡 Hint

Consider what 'eventual' means in terms of data synchronization over time.

Eventual consistency allows temporary stale reads but guarantees that all replicas will eventually have the same data.

❓ Architecture

advanced

Designing a System for Strong Consistency

Which architectural component is essential to ensure strong consistency in a distributed key-value store?

A A caching layer that serves stale data for faster reads.

B A background process that asynchronously syncs replicas after writes.

C A load balancer that directs reads to any available replica.

D A consensus protocol like Paxos or Raft to coordinate writes across replicas.

💡 Hint

Think about how replicas agree on the order of writes.

Consensus protocols ensure all replicas agree on the order and success of writes, which is necessary for strong consistency.

❓ scaling

advanced

Scaling Eventual Consistency Systems

What is a common tradeoff when scaling an eventually consistent distributed database to many replicas?

A Temporary data inconsistency across replicas during replication delays.

B Increased write latency due to synchronous replication to all replicas.

C Reduced read throughput because all reads must go to the primary node.

D Complete data loss risk if one replica fails.

💡 Hint

Consider what happens when many replicas update asynchronously.

As the number of replicas grows, the time to propagate updates increases, causing temporary inconsistencies.

❓ tradeoff

expert

Choosing Consistency Models for a Global Application

A global social media platform wants to balance user experience and data correctness. Which consistency model should it choose and why?

A Strong consistency only for writes, eventual consistency for reads.

B Strong consistency to ensure all users see the exact same data immediately, sacrificing latency.

C Eventual consistency to provide low latency and availability, accepting temporary stale data.

D No consistency guarantees to maximize throughput and ignore data correctness.

💡 Hint

Think about user experience in a global system with many users and locations.

Eventual consistency offers better latency and availability globally, which is often preferred in social media despite temporary stale data.