AZ-305 Design data storage solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Azure Cosmos DB for all three services.

  Why it's wrong here

  While Azure Cosmos DB is a globally distributed, multi-model NoSQL database that offers low-latency reads and tunable consistency, it is not the best fit for every service. Order processing demands strong ACID transactions across multiple rows and tables, but Cosmos DB's transactional guarantees are limited to single-partition operations or stored procedures, and multi-partition transactions are not equivalent to a relational engine. For the shopping cart, Cosmos DB adds unnecessary cost and complexity compared to an in-memory cache, and its per-request latency, while low, is still not sub-millisecond like Redis. Therefore, using Cosmos DB for all three sacrifices transactional integrity and over-allocates a globally distributed store where a simpler, faster cache is appropriate.

• ✗

  Azure Table Storage for shopping cart, Azure SQL Database for orders, Azure Cosmos DB for product catalog.

  Why it's wrong here

  Azure Table Storage is a durable NoSQL key-value store, but it is designed for cold or warm structured data rather than ultra-low-latency hot-path workloads. Shopping cart operations are high-frequency, write-heavy, and latency-sensitive; Table Storage typically incurs 5-10 ms predictable latency, and it lacks the in-memory data structures, TTL-based expiration, and session-caching features that Azure Cache for Redis provides. While assigning Azure SQL Database and Azure Cosmos DB for the other two services is reasonable, the shopping cart component would be the bottleneck, causing a sluggish checkout experience under load. Thus, the combination works only if the cart is small-scale or latency is not a strict requirement.

• ✓

  Azure Cache for Redis for shopping cart, Azure SQL Database for orders, Azure Cosmos DB for product catalog.

  Why this is correct

  This combination correctly applies the polyglot persistence pattern to match each workload's access requirements. Azure Cache for Redis is an in-memory data store with sub-millisecond latency and built-in TTL, making it ideal for a transient, write-heavy shopping cart that must survive user sessions but not act as a durable system of record. Azure SQL Database provides full ACID compliance, relational integrity, and rich indexing, which are mandatory for order processing because every order transaction must be atomic and isolated. Azure Cosmos DB's flexible document model, tunable consistency levels, and global distribution allow a product catalog to be cached at edge regions and served with low latency while accommodating evolving product attributes. Together they address latency, consistency, and scalability where each technology is strongest.

• ✗

  Azure SQL Database for all three services.

  Why it's wrong here

  Using Azure SQL Database for all three services would force a relational schema onto a shopping cart workload that is best modeled as a simple key-value store, causing unnecessary overhead for each add/update/delete. Azure SQL Database's performance is strong, but it does not offer the sub-millisecond, in-memory caching latencies that a high-write cart requires, and scaling it for that purpose is cost-inefficient. For the product catalog, a relational schema struggles with schema evolution and global distribution—features like multi-region writes are not native, and changing product attributes requires expensive schema migrations. While orders are a perfect fit for SQL, the cart and catalog requirements are better served by non-relational, distributed data stores.

Go deeper

Related to this question