CH06-01: Data Selection Mental Model

Goal

The previous chapters in Part 2 asked how code runs and how systems communicate. Data selection asks a different question: where should each kind of data live so the workload can read it, change it, protect it, scale it, and pay for it sensibly?

This section introduces data service selection as a responsibility-matching decision. The goal is not to memorize every Azure database and storage option. The goal is to learn how to recognize the shape of the data and the behavior the application expects from it.

The durable idea for this chapter is:

Choose a data service by how the workload uses the data, not by the label on the database.

The Short Version

Data service selection decides the operating home for data. That home affects query behavior, consistency, transaction boundaries, scaling, lifecycle management, backup, recovery, security, and cost.

The easy question is:

Which Azure service stores this data?

The better architecture question is:

What shape is this data, how will the application access it, and what guarantees does the business need from it?

Many services can store bytes. That does not make them interchangeable. An order record, a product image, a user session document, an invoice PDF, and an analytics export are all data, but they do not have the same access pattern or lifecycle.

Do not worry if several service names appear early. Azure SQL, Azure Cosmos DB, Azure Blob Storage, and Azure Files will each get their own explanation. For now, focus on the data responsibility each service is designed to carry.

The Data Responsibility Map

Start with the job of the data before choosing the product.

Data need
    |
    +-- Relational records and transactions -> Azure SQL
    +-- Document access and global scale     -> Azure Cosmos DB
    +-- Objects, media, backups, logs         -> Azure Blob Storage
    +-- Shared file access                    -> Azure Files

This is a simplified map, not a complete Azure data catalog. Azure has many more data services for analytics, caching, search, time-series data, open-source databases, and specialized workloads. This chapter focuses on four common responsibilities because they appear in many application architectures.

Decision Dimensions

Evaluate the data from the application outward.

These questions are more useful than starting with "SQL or NoSQL?" A relational database can be the cleanest answer for one part of a system. A document database can be the cleanest answer for another. Object storage may be the right home for large files that should never have been stored in database rows. A file share may be needed because an application expects file system behavior.

Query Pattern Comes Early

Data size matters, but query pattern usually matters earlier.

Ask:

• Does the application usually retrieve one item by ID?

• Does it query many records by customer, date, status, or category?

• Does it need joins across related entities?

• Does it update several records in one transaction?

• Does it read and write a whole document as an application aggregate?

• Does it stream, download, or archive large objects?

• Does a legacy component expect a mounted path and file locking behavior?

The same number of gigabytes can behave very differently depending on these answers. A few hundred gigabytes of well-indexed relational order data is not the same design problem as a few hundred gigabytes of images, logs, session documents, or shared files.

One Application Can Need Several Stores

A common trap is choosing one data service for the whole application too early.

Consider a commerce platform:

Commerce platform
    |
    +-- Orders and payments
    +-- Product catalog
    +-- User sessions
    +-- Product images
    +-- Invoice PDFs
    +-- Analytics exports
    +-- Shared operations folder

Orders and payments may need relational integrity. Product catalog records may fit a document model if the application reads product aggregates frequently and the schema changes over time. Product images and invoice PDFs are object data. Analytics exports may be stored as files in object storage for later processing. A small operations workflow might still need a shared file path because a legacy tool expects one.

The architecture does not become weaker because it uses more than one data service. It becomes weaker when data is split without ownership, consistency boundaries, lifecycle rules, and operational discipline.

Mixed Does Not Mean Random

Using several data services is sometimes called polyglot persistence. The useful version is deliberate: each store has a clear job, and the boundaries between stores are designed.

The risky version is accidental: every team picks a favorite database, data is duplicated without rules, reporting pipelines become unclear, and nobody can explain which store is authoritative.

When a workload uses more than one data service, write down:

• Which store owns the source of truth for each data responsibility.

• Which data is copied, projected, exported, or cached.

• How updates move between stores.

• What happens when synchronization fails.

• Which teams own backup, restore, monitoring, access, and cost.

This turns a mixed data architecture from a pile of services into a system with understandable boundaries.

Example: First-Pass Data Classification

For the commerce platform, a first classification might look like this:

This table is not the final design. It is a responsibility map. The later sections explain how to refine each choice.

Common Mistakes

• Choosing a database before understanding query patterns.

• Treating NoSQL as automatically better, cheaper, or more modern.

• Putting large binary files into relational tables by habit.

• Using object storage when the application needs file-share semantics.

• Splitting data across services without ownership and synchronization rules.

• Ignoring retention, backup, restore, redundancy, and cost until data growth makes them urgent.

If Someone Asks You

How do you choose an Azure data service?

A good answer is:

I start with the data shape and access pattern. I ask whether the workload needs relational transactions, document-style aggregate access, object storage, or shared file behavior. Then I check consistency, scale, lifecycle, backup, security, and cost. One application may use several data services, but each store should have a clear responsibility and ownership boundary.

What You Should Remember

Data architecture starts with how data is shaped, queried, changed, protected, and retained.

Questions to Check Your Understanding

1. Why is query pattern as important as data size?

2. When might one workload need multiple data services?

3. Which data requirements should be known before selecting a service?