CH06-05: Scale, Consistency, and Cost Trade-Offs

Goal

The earlier sections explained the main data responsibilities in this chapter: relational data, document data, object storage, and shared file storage. This section compares the trade-offs that show up after the first service choice.

Data selection is not finished when the data can be stored. The choice affects scale, consistency, lifecycle, backup, recovery, security, operations, and cost for as long as the workload lives.

The durable idea is:

Data trade-offs are workload behavior trade-offs: scale, consistency, cost, and operations move together.

The Short Version

Every data service has a scale model and an operating model.

Azure SQL scaling is shaped by schema, indexes, queries, service tier, compute, storage, and transaction patterns. Cosmos DB scaling is shaped by partition keys, request units, document size, indexing, regions, and access patterns. Blob Storage scaling is shaped by object count, object size, access frequency, lifecycle, redundancy, and request patterns. Azure Files scaling is shaped by share performance, protocol behavior, mounted clients, snapshots, backup, and workload expectations.

The lowest storage price is not always the lowest data architecture cost.

Trade-Off Map

Use this table as a practical comparison, not as a complete service specification.

Concern	Azure SQL	Azure Cosmos DB	Azure Blob Storage	Azure Files
Scale question	How do queries, indexes, transactions, and capacity grow?	Does the partition key distribute data and throughput well?	How do object count, object size, and access frequency grow?	How many clients, operations, and file-share workloads are expected?
Consistency question	Which transactions and reads must be strongly consistent?	Which consistency level matches user and regional behavior?	What object write, read, versioning, and replication behavior does the app expect?	What file system behavior, locking, and concurrent access does the app expect?
Cost drivers	Compute, storage, service tier, backup retention, replicas, query performance.	Request units, storage, indexing, regions, consistency, autoscale or serverless model.	Storage tier, operations, redundancy, data retrieval, lifecycle, retention.	Provisioned or used capacity, performance tier, snapshots, backup, transactions, redundancy.
Operations	Schema, indexes, performance, backup, restore, security, monitoring.	Partitioning, RU monitoring, indexing policy, consistency, regional design, cost control.	Lifecycle, access tiers, redundancy, private access, retention, immutability, monitoring.	Share permissions, mount behavior, backup, sync, performance, access, legacy dependency management.
Common mistake	Assuming managed SQL removes database design.	Choosing Cosmos DB without an access and partition model.	Keeping everything hot forever.	Using a file share when object storage would fit better.

The table should make one thing clear: every option needs design work. Managed services reduce certain kinds of platform work, but they do not remove responsibility for data behavior.

Scale Is Not One Thing

Scale means different things for different data services.

For Azure SQL, scale may mean larger compute, better indexes, query tuning, partitioning strategies, read replicas, elastic pools, or archiving old data.

For Cosmos DB, scale usually starts with partition-key design. If traffic concentrates on a few partition values, the workload can hit hot partitions even when the overall account looks large enough. If queries often cross partitions, the cost and latency can surprise the team.

For Blob Storage, scale may mean millions of objects, large objects, high request rates, many prefixes, long retention, data lake structures, or frequent retrieval from cooler tiers.

For Azure Files, scale may mean many clients mounting a share, application expectations around file locking, performance tiers, snapshots, backup windows, and network access.

Do not ask only, "Can the service scale?" Ask, "Can our access pattern scale on this service?"

Consistency Is a User Promise

Consistency choices should come from user and business behavior.

Ask:

After a payment is accepted, where must the new state appear immediately?
Can a product catalog update take a short time to appear globally?
Can an analytics export lag behind operational data?
Can a user session tolerate eventual synchronization?
Which data must be protected against partial updates?

For relational systems, consistency often appears as transaction design. For Cosmos DB, consistency levels and regional replication are explicit architecture decisions. For storage, consistency and replication choices show up through object writes, versioning, redundancy, failover, and read access patterns. For file shares, consistency appears through file system expectations and concurrent access behavior.

Users do not care which consistency model sounds elegant. They care whether the application behaves in a way they can trust.

Lifecycle Is Cost Control

Data becomes expensive when it grows without a plan.

Lifecycle questions include:

How long must operational data stay in the hot path?
When can old records move to archive tables or exports?
Which blobs can move from hot to cool or archive tiers?
Which logs are retained for troubleshooting, audit, or compliance?
Which snapshots and backups are kept, and for how long?
Which data must be deleted because of policy or privacy requirements?

Lifecycle is especially visible with Blob Storage because access tiers and lifecycle rules can move or delete objects based on age or access patterns. But the same principle applies everywhere. A relational table with ten years of operational history, a Cosmos DB container with unbounded documents, and a file share full of forgotten exports all become cost and operations problems.

Backup, Restore, and Redundancy Are Separate Questions

Redundancy protects availability and durability. Backup and restore protect recovery from deletion, corruption, mistakes, and business events. They are related, but they are not the same design.

Ask:

What failure is redundancy meant to survive?
What deletion or corruption scenario must backup survive?
How far back must the team be able to restore?
Has restore been tested, or only configured?
Which data has regional disaster recovery requirements?
Which data must be immutable or protected from accidental deletion?

For storage accounts, redundancy choices such as local, zone, or geo redundancy affect durability, availability, and cost. For databases, backup retention, point-in-time restore, failover, and regional design require service-specific planning. The key is to state the recovery requirement before selecting the option.

Security and Private Access Stay Close to Data

Data service choice also affects security.

Plan:

Identity-based access where possible.
Least-privilege permissions.
Separate environments and ownership boundaries.
Private endpoints or network restrictions for private data paths.
Encryption and key management.
Auditing and activity logs.
Monitoring and alerting for unusual access or cost changes.
Classification for sensitive data.

Do not postpone data security until after the service is live. Access patterns, network placement, and identity model can be harder to change later.

Example: Growth Pressure in a Commerce Platform

The commerce platform starts small, then grows.

Order volume increases. Azure SQL may need index review, query tuning, capacity changes, retention design, and restore testing.

The product catalog expands globally. Cosmos DB may be a strong fit if the document model and partition key support the access pattern, but global distribution and RU cost must be tested.

Product images accumulate for years. Blob Storage needs lifecycle policies, access tiers, retention rules, private access, and possibly separate containers or accounts for different ownership and redundancy needs.

Analytics exports grow quickly. Blob Storage may still be right, but the team needs naming conventions, lifecycle, data classification, and downstream processing ownership.

The operations file share becomes a dependency. Azure Files can keep the workflow running, but the team should monitor usage, back it up, and decide whether the file-share dependency remains strategic or becomes a modernization item.

Cost Review Questions

Use these questions before finalizing a data choice:

Question	Why It Matters
What are the top reads and writes?	Reveals whether the service's access model fits.
What happens when traffic doubles?	Exposes scale, partitioning, indexing, and capacity decisions.
What happens when data grows for five years?	Forces lifecycle, retention, and archive planning.
What must be restored after an accident?	Separates backup requirements from availability assumptions.
Which data is sensitive?	Drives identity, encryption, private access, and auditing.
Which data can be eventually consistent?	Prevents overpaying or overcomplicating the consistency model.
Who owns the data store after launch?	Turns service selection into an operating responsibility.

These questions make the data decision more honest.

Common Mistakes

Choosing a service before modeling read and write patterns.
Ignoring retention and lifecycle policies until storage costs grow.
Treating consistency as a technical detail instead of user-visible behavior.
Forgetting backup and restore testing.
Designing for global scale when the business does not need it yet.
Comparing only storage capacity and ignoring operations, requests, throughput, redundancy, and data movement.

If Someone Asks You

What trade-offs matter when choosing Azure data services?

A good answer is:

I compare data services by access pattern, consistency, scale model, lifecycle, recovery, security, operations, and cost. Azure SQL, Cosmos DB, Blob Storage, and Azure Files all store data, but they scale and charge differently. The right choice is the one whose behavior matches the workload over time, not only the one that looks easy on day one.

What You Should Remember

Data service choice is a long-term operating decision, not only a storage location.

Questions to Check Understanding

Why should query patterns be known before choosing a data service?
How can consistency choices affect users?
What cost drivers should be considered beyond storage capacity?