Consistency Essentials in Global Distributed Databases Quiz Quiz

Explore the core principles and practical aspects of consistency models in global distributed databases, including how data remains accurate and up-to-date across geographically dispersed nodes. This quiz is designed to help learners understand strong and eventual consistency, transaction guarantees, and related concepts in distributed database systems.

1. Understanding Strong Consistency

   Which statement best describes strong consistency in a global distributed database scenario?

   1. Data is available in some regions only during a network partition.
   2. A read always returns the latest committed write across all regions.
   3. All replicas remain eventually consistent after a delay.
   4. Writes are ignored during high latency events.

   Explanation: Strong consistency ensures that after a write completes, any subsequent read will reflect that write in all regions. The other options are incorrect because data being available in only some regions describes availability trade-offs, eventual consistency allows for delayed synchronization, and ignoring writes during latency does not define consistency.

2. Eventual Consistency Defined

   What does eventual consistency guarantee in global distributed databases?

   1. Only the nearest node returns consistent results.
   2. Transactions always complete in real time.
   3. Data will become consistent across replicas if no new updates are made.
   4. All updates are visible immediately in every region.

   Explanation: Eventual consistency means that given enough time without new updates, all replicas will converge to the same value. Immediate visibility is false, as delays can occur. Real-time completion and nearest node consistency do not accurately describe eventual consistency's behavior.

3. Leader-Follower Replication and Consistency

   In a global database, how does leader-follower replication help achieve consistency?

   1. All writes must be approved by every follower before committing.
   2. Followers perform uncoordinated writes to improve speed.
   3. Reads and writes always occur on any randomly selected node.
   4. Writes are sent to a single leader, which propagates changes to followers.

   Explanation: Leader-follower replication centralizes writes on a leader node, which then synchronizes followers to maintain consistency. Requiring all followers to approve writes is not standard and reduces efficiency. Selecting nodes at random can break consistency. Followers performing uncoordinated writes risks divergent data.

4. Consistency Models Comparison

   Which scenario best demonstrates the difference between strong and eventual consistency?

   1. A user updates their profile, and different regions show different data briefly.
   2. An application only supports offline mode.
   3. A database automatically scales with workload.
   4. A transaction fails due to lack of network connectivity.

   Explanation: Seeing different profile data in various regions after an update is a hallmark of eventual consistency, which does not guarantee immediate propagation. Transaction failure describes availability, offline mode is unrelated to consistency, and automated scaling pertains to performance, not consistency.

5. CAP Theorem in Global Databases

   According to the CAP theorem, what can be compromised in favor of consistency and partition tolerance in distributed systems?

   1. Availability
   2. Concurrency
   3. Atomicity
   4. Bandwidth

   Explanation: CAP theorem states that during a network partition, a system can choose either consistency or availability, not both. Concurrency and atomicity refer to transaction characteristics, not CAP. Bandwidth is unrelated to the theorem.

6. Read-your-write Consistency Explained

   What does read-your-write consistency guarantee for a single client?

   1. Old data can overwrite recent updates during conflicts.
   2. Every client sees the same data at the same time.
   3. Writes by one client are never visible to others.
   4. Reads by a client reflect their most recent writes immediately.

   Explanation: Read-your-write consistency allows clients to read their own updates right away, reinforcing correctness for the user's actions. It does not guarantee synchronization across clients, nor does it prevent others from seeing changes. Allowing overwrites of recent updates by old data is a conflict, not consistency.

7. Quorum-based Consistency Basics

   How does a quorum mechanism contribute to consistency in global distributed databases?

   1. Only one node can read and write data at any time.
   2. It requires a majority of nodes to acknowledge an operation before it is considered committed.
   3. Nodes ignore failed acknowledgments for faster performance.
   4. It forces all nodes to process every operation twice.

   Explanation: A quorum ensures that a write is only committed when most nodes have acknowledged it, promoting consistency across the system. Processing every operation twice or limiting to one node contradicts distributed principles, and ignoring failed acknowledgments risks inconsistency.

8. Multi-region Latency Impact

   Why can strong consistency increase latency in multi-region global databases?

   1. All data is always stored in a single region.
   2. Data must be synchronized across multiple regions before confirming writes.
   3. Reads and writes are randomly delayed to avoid collisions.
   4. Clients must manually resolve conflicts after every update.

   Explanation: Ensuring strong consistency often means waiting for confirmation from multiple regions, adding to response time due to network delays. Storing data in one region avoids multi-region latency, manual conflict resolution is part of conflict handling, and random delays do not guarantee consistency.

9. Consistency Guarantees and Failovers

   What happens to consistency guarantees when a node fails in a strongly consistent, replicated database?

   1. The system maintains consistency but may reduce availability during failover.
   2. New writes are ignored until the node recovers.
   3. All data becomes unavailable across the global database.
   4. Reads return random results from any replica.

   Explanation: When a node fails, strong consistency systems still enforce correct data but might limit availability until redundancy is restored. Data does not become completely unavailable, writes are not ignored, and reads do not return random results as these all contradict strong consistency.

10. Stale Reads in Distributed Systems

    What is a 'stale read' in the context of global distributed databases?

    1. Writing data without confirming it was saved.
    2. Reading older data that has not been updated to reflect the latest writes.
    3. Overwriting data before it is read by other nodes.
    4. Accessing data during a system maintenance window.

    Explanation: A stale read occurs when a node returns outdated data that does not include the most recent updates. Writing without confirming affects durability, not consistency. Overwriting before synchronization and accessing data during maintenance are different operational concerns.