Start Data Decisions With Access Patterns
Goal
Open the chapter with the questions that describe data before a storage or database product is selected.
The Short Version
Choose data capabilities from the way information is created, queried, changed, shared, retained, and recovered.
A workload profile should capture entities, volume, velocity, query shape, transaction boundaries, consistency, latency, and growth. The important architecture move is to make the boundary explicit before selecting a cloud feature. A feature can automate a decision, but it cannot decide the organization's risk tolerance, ownership model, or acceptable failure behavior.
Use this section as a decision tool. Name the actor or producer, the protected or affected resource, the contract between them, the conditions under which the action is allowed, and the evidence that will show whether the design worked.
Mental Model
Use a data decision canvas linking producers and consumers to access, correctness, lifecycle, governance, recovery, and cost requirements.
flowchart LR
N1["Business operation"] --> N2["Access pattern"] --> N3["Data model"] --> N4["Consistency and lifecycle"] --> N5["Store"] --> N6["Governance evidence"]Read the diagram from left to right, then review it from right to left. The forward pass explains how work succeeds. The reverse pass asks whether an operator can trace an outcome back to its initiating identity, input, policy, route, or contract.
Architecture Decisions
| Decision dimension | Question to make explicit |
|---|---|
| Access | Which reads, writes, queries, and aggregations dominate? |
| Correctness | Which invariants require transactions or strong consistency? |
| Scale | How do volume, velocity, partitioning, and latency change the design? |
| Lifecycle | How long is data retained, replicated, backed up, and recoverable? |
| Governance | Who owns classification, access, lineage, quality, and deletion? |
The answers should be recorded with the workload design. If the answer is merely "the platform default," the team has discovered an assumption, not completed an architecture decision.
Core Ideas
A workload profile should capture entities, volume, velocity, query shape, transaction boundaries, consistency, latency, and growth
A workload profile should capture entities, volume, velocity, query shape, transaction boundaries, consistency, latency, and growth. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Durability, availability, backup, retention, residency, privacy, lineage, and deletion are distinct requirements
Durability, availability, backup, retention, residency, privacy, lineage, and deletion are distinct requirements. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Systems of record, derived views, caches, search indexes, analytical copies, and archives need different ownership and freshness expectations
Systems of record, derived views, caches, search indexes, analytical copies, and archives need different ownership and freshness expectations. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Provider Lenses
AWS implements these models with services such as S3, EBS, EFS, RDS or Aurora, DynamoDB, Redshift, and OpenSearch. Azure offers Blob Storage, Managed Disks, Azure Files, Azure SQL, Cosmos DB, analytical platforms, and Azure AI Search. These are model implementations with different operational and consistency boundaries, not a flat equivalence table.
Provider lenses are useful for implementation planning, but they should come after the provider-neutral decision. This keeps the reasoning portable and makes differences in defaults, scope, and operational responsibility easier to detect.
Example: Applying the Decision
Profile product catalog, order, image, search, reporting, and audit data for an online retailer before naming technologies.
Keep orders in a transactional system of record, product images in object storage, search documents in a rebuildable index, low-risk hot reads in a cache, and governed historical copies in an analytical platform. Define ownership and reconciliation between each copy.
A review should finish with named owners, a testable success path, expected failure modes, and observable evidence. That is more useful than a diagram that only proves the components can connect.
Common Mistakes
Choosing a database from familiarity before listing queries and correctness needs. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Using availability, durability, backup, and disaster recovery as interchangeable terms. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Creating copies without owners, freshness expectations, or deletion rules. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
If Someone Asks You
What should you know before choosing a cloud data service?
A clear answer is:
Choose data capabilities from the way information is created, queried, changed, shared, retained, and recovered.
I would then show the decision path, the responsibility boundary, and the evidence used to review it. That explanation connects the technical mechanism to its architecture purpose.
What You Should Remember
Choose data capabilities from the way information is created, queried, changed, shared, retained, and recovered.
Questions to Check Your Understanding
Which facts define an access pattern?
Why are derived copies separate architecture responsibilities?
Which lifecycle and recovery questions belong in the first design conversation?
Further Study
AWS Well-Architected: Choose data storage based on access patterns - Use this authoritative source to deepen the section's provider-neutral control and decision model.