DP-420 Question #127: Real Exam Question with Answer & Explanation

Question

Drag and Drop Question You are designing three apps named App1, App2, and App3. Each app will use a separate Azure Cosmos DB for NoSQL account. The apps have the following consistency requirements: - App1: Reads must always return the most recent committed version of an item, where the commit occurred during the same session. - App2: Reads must always return the most recent committed version of an item, even if the commit occurred during another session. - App3: Write latency must be minimized and data staleness can be tolerated. You need to recommend a default consistency level for each Azure Cosmos DB for NoSQL account. The solution must minimize concurrency. What should you recommend for the account of each app? To answer, drag the appropriate consistency levels to the correct apps. Each consistency level may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content. NOTE: Each correct selection is worth one point. Answer:

Explanation

This question assesses the ability to select appropriate Azure Cosmos DB consistency levels for different application requirements, balancing data consistency, read/write latency, and system overhead.

Approach. The task is to match each application's consistency requirements to one of Azure Cosmos DB's five consistency levels. The solution must minimize concurrency, which generally means choosing the least strict consistency level that still meets the requirements.

• App1 Requirements: 'Reads must always return the most recent committed version of an item, where the commit occurred during the same session.' This is the precise definition of Session consistency. Session consistency guarantees that a client session will read its own writes and reads will be monotonic (never see an older version after a newer one).

• App2 Requirements: 'Reads must always return the most recent committed version of an item, even if the commit occurred during another session.' This requires the highest level of consistency, where all reads across all clients and regions see the most up-to-date committed data. This is achieved by Strong consistency.

• App3 Requirements: 'Write latency must be minimized and data staleness can be tolerated.' The consistency level that offers the lowest write latency and allows for the highest degree of data staleness is Eventual consistency. This level provides no ordering guarantees for reads, but eventually, all replicas will converge to the same state.

Common mistakes.

• common_mistake. Common mistakes include misinterpreting the specific guarantees of each consistency level. For instance:
• Using Bounded Staleness or Consistent Prefix for App1 or App2: While these offer stronger guarantees than Eventual, they do not strictly meet the requirements. Bounded Staleness allows reads to lag behind writes by a configured time or version interval, and Consistent Prefix guarantees that reads will return writes in the order they were performed, but not necessarily the absolute latest version globally (Strong) or within a session (Session).
• Using a stricter consistency level (e.g., Strong or Session) for App3: If App3 can tolerate data staleness and prioritizes minimized write latency, using a stricter level like Session, Bounded Staleness, or Strong would introduce unnecessary latency and higher Request Units (RUs) without providing additional value for the application's specific needs. For example, Strong consistency significantly increases write latency due to the need for synchronous replication across all regions.
• Confusing Session and Strong: Session consistency only guarantees 'read-your-own-writes' and monotonic reads within a single client session, whereas Strong consistency guarantees global, immediate consistency across all clients and regions.

Concept tested. Azure Cosmos DB for NoSQL consistency models (Strong, Bounded Staleness, Session, Consistent Prefix, Eventual), their characteristics, and the trade-offs between consistency, availability, and latency (CAP theorem / PACELC theorem).

Reference. null

No community discussion yet for this question.