CH06-06: Data Choice Scenario

Goal

This section applies the Chapter 6 data selection model to a realistic commerce platform.

The goal is not to produce the only possible architecture. The goal is to show how a team can explain data choices by matching each kind of data to its shape, query pattern, consistency needs, lifecycle, and operating responsibility.

The durable idea is:

A strong data architecture gives each kind of data the store that matches its shape, query pattern, and lifecycle.

Scenario

A commerce platform needs to store and process several kinds of data:

• Product catalog data.

• Orders and payments.

• User session state.

• Product images.

• Invoice PDFs.

• Analytics exports.

• A small shared operations folder used by a legacy workflow.

Some data needs relational integrity. Some data may fit flexible document access. Some data is large binary object data. Some legacy components expect file-share access.

The design challenge is not to pick one database for everything. A strong answer gives each data responsibility a clear home and then designs the boundaries between stores.

Restating the Architecture Problem

Before choosing services, translate the scenario into data questions:

These questions prevent the design from turning into a service-name list.

Proposed Data Model

One pragmatic first design is:

Commerce platform
	|
	+-- Azure SQL
	|       +-- Orders
	|       +-- Order lines
	|       +-- Payments
	|       +-- Invoice metadata
	|
	+-- Azure Cosmos DB, if access pattern fits
	|       +-- Product catalog documents
	|       +-- Durable user session documents, if needed
	|
	+-- Azure Blob Storage
	|       +-- Product images
	|       +-- Invoice PDFs
	|       +-- Backups, logs, and analytics exports
	|
	+-- Azure Files
			+-- Shared operations folder for legacy workflow

This model uses several data services because the workload has several data responsibilities. The design stays coherent because each store has a clear reason.

Orders and Payments

Orders and payments are the clearest Azure SQL candidate.

They have relationships:

• Customers place orders.

• Orders contain order lines.

• Payments apply to orders.

• Invoices refer to completed purchases.

• Refunds, shipment status, and tax records may depend on accurate history.

They also have transaction needs. A payment record should not drift casually away from the order it paid for. An order should not be half-created without the required line items. Business reporting and operational troubleshooting often need SQL-style queries over this data.

A simplified relational boundary is:

Azure SQL
	|
	+-- Customers
	+-- Orders
	+-- OrderLines
	+-- Payments
	+-- InvoiceRecords

The team still needs schema design, indexes, backup, restore testing, private access, identity, auditing, and monitoring. Azure SQL is managed, but the business data model still belongs to the team.

Product Catalog

The product catalog needs a closer look.

Cosmos DB may fit if products are usually read as complete documents, product attributes vary by category, the catalog changes frequently, and regional low-latency reads matter. For example, a clothing item, electronics item, and grocery item may have different attribute shapes while still being served through one catalog API.

Catalog API
	|
	+-- Read product by productId
	+-- Query tenant/category views
	+-- Update product document as an aggregate

Before choosing Cosmos DB, the team should define:

• The main read and write paths.

• The partition key.

• Expected document size.

• Query patterns that need indexes.

• Whether search belongs in a separate search service.

• Consistency needs for regional catalog updates.

• RU cost under expected traffic.

If the catalog is actually full of relational rules, complex joins, and strict transactional updates across many entities, Azure SQL may be better. If the catalog is mainly document-shaped and read-heavy, Cosmos DB may be a better fit.

User Sessions

User session state is not automatically a database decision.

Ask whether the session is:

• Temporary and rebuildable.

• Durable and business-relevant.

• Latency-sensitive.

• Needed across regions.

• Better stored as a cache, document, token, or server-side state record.

Cosmos DB can be a fit for durable, key-based session documents with low-latency access. A cache may be a better fit for temporary session acceleration. Azure SQL may be right if the session state is really part of a relational business workflow. The architecture answer depends on what the session means.

Images, PDFs, Logs, and Exports

Product images, invoice PDFs, logs, backups, and analytics exports are Blob Storage candidates.

Blob Storage is a better fit than a relational table for large object data because the application usually stores, retrieves, serves, archives, or processes the whole object.

Blob Storage
	|
	+-- product-images/
	+-- invoice-pdfs/
	+-- analytics-exports/
	+-- logs/

The database can hold metadata and references:

This split keeps the system honest. Databases manage business facts and queryable metadata. Blob Storage manages durable objects and lifecycle.

Shared Operations Folder

The legacy operations folder is the Azure Files candidate.

If the process expects a mounted path, directory structure, and file-share semantics, Azure Files can support the migration without redesigning the workflow immediately.

Operations users or legacy process
	|
	v
Azure Files share
	|
	+-- imports/
	+-- exports/
	+-- exceptions/

This choice should come with a review point. A shared file workflow may be acceptable during migration, but it should not remain invisible. The team should monitor usage, protect access, back up the share, and decide whether the workflow should eventually move to object storage, an integration service, or a purpose-built application flow.

Cross-Cutting Design

Using several data services does not mean every data store gets its own unmanaged operating model.

Standardize the cross-cutting concerns:

This is how a mixed data architecture stays understandable.

Requirement-to-Service Map

The key is that every data choice has an explanation. In architecture discussions, that explanation matters more than naming the service quickly.

Trade-Offs

This design favors fit over uniformity.

It uses Azure SQL where consistency, relationships, and SQL queries matter. That keeps transactional business data clear, but it requires database design and operational care.

It uses Cosmos DB only where document access, partitioning, scale, and latency requirements justify it. That prevents a vague "NoSQL everywhere" design, but it requires the team to define access patterns early.

It uses Blob Storage for objects and exports. That keeps large binary data out of databases and supports lifecycle policies, but it requires thoughtful naming, metadata, access control, retention, and cost management.

It uses Azure Files for a legacy shared folder. That reduces migration risk, but it keeps a file-share dependency that should have an owner and modernization review.

Good architecture is not pretending one service can satisfy every data shape. Good architecture makes the trade-offs visible and manageable.

Common Mistakes

• Putting all data into one database for convenience.

• Splitting data across stores without clear ownership and consistency boundaries.

• Choosing Cosmos DB without a partitioning and query model.

• Forgetting retention, private access, and backup for object storage.

• Keeping shared file workflows forever without a modernization plan.

• Duplicating data into several stores without explaining which copy is authoritative.

If Someone Asks You

How would you choose Azure data services for a commerce platform?

A good answer is:

I would classify the data by shape and access pattern. Orders, payments, and invoice metadata likely belong in Azure SQL because they are relational and transactional. Product catalog or durable session documents may fit Cosmos DB if the access pattern and partition key are clear. Product images, invoice PDFs, logs, and exports belong in Blob Storage. A legacy shared operations folder can use Azure Files if it truly needs file-share semantics. Then I would design identity, private access, backup, lifecycle, monitoring, cost, and ownership across all stores.

What You Should Remember

Let each data responsibility choose its store, then design the boundaries between stores carefully.

Questions to Check Understanding

1. Which data in the scenario is most clearly relational?

2. Which data is most clearly object storage?

3. What risks appear when a workload uses several data services?