E-Commerce Data Placement Scenario

Goal

The chapter has built a decision model: name the data job, identify the source of truth, choose the access pattern, and then map the responsibility to AWS services.

This section applies that model to a realistic e-commerce platform. The point is not to create one perfect reference architecture. The point is to practice a conversation-ready recommendation.

The Short Version

A good data architecture gives each data shape the right home and the right responsibility.

When a retailer asks for "the best database," a stronger answer is:

There probably is not one database for the whole platform. Product images, orders, payments, catalog reads, search, analytics, sessions, backups, and archives have different access patterns and ownership rules. I would map each data responsibility first, then choose AWS services around source of truth, derived copies, consistency, recovery, lifecycle, security, and cost.

Scenario

A retailer is moving a growing online store to AWS. The platform needs:

• Product catalog management.

• Product images and static assets.

• Customer-facing product reads.

• Shopping carts and sessions.

• Orders and payments.

• Inventory availability.

• Product search.

• Sales analytics.

• Backups, audit records, and long-term retention.

The business asks, "Should we use S3, DynamoDB, or Aurora?"

The architecture answer is: "For which data responsibility?"

A Practical Data Placement Map

One possible AWS data placement map looks like this:

Commerce platform
  |
  +-- S3
  |     product images, static assets, data lake objects, exports, archives
  |
  +-- Aurora or RDS
  |     orders, payments, audit-sensitive transactional state
  |
  +-- DynamoDB
  |     high-scale known access patterns such as carts, sessions, or catalog reads
  |
  +-- OpenSearch
  |     product search and filtering as a derived index
  |
  +-- Redshift or S3 data lake
  |     sales analytics, BI, historical reporting
  |
  +-- ElastiCache
  |     hot reads or temporary low-latency data where cache behavior is acceptable
  |
  +-- AWS Backup, snapshots, lifecycle policies
        recovery, retention, archive, and cost control

This map is intentionally responsibility-based. It avoids pretending one service is the answer to every data problem.

Source Of Truth Decisions

The source-of-truth choices should be explicit.

Orders and payments usually need strong transactional design, auditability, controlled updates, and careful recovery. A relational store such as Aurora or RDS is often a credible fit. The exact engine depends on team skill, licensing, operational needs, compatibility, and performance expectations.

Product catalog management may also fit a relational model if editors need workflow, relationships, constraints, and flexible operational queries. But high-volume customer-facing catalog reads may be served from a derived DynamoDB read model, cache, or search index depending on the access pattern.

Product images belong naturally in S3 because they are objects. S3 can support lifecycle policies, replication, access controls, event-driven processing, and integration with delivery patterns. The product database should store metadata and references, not necessarily the image bytes.

Search belongs in OpenSearch when customers need text search, filtering, relevance, and exploration. But the index should be rebuildable from source product data. It should not become the only place where product truth lives.

Analytics belongs in Redshift or a data lake pattern on S3 when the business needs aggregate reporting. Analytics data may be delayed, transformed, and curated. That is fine as long as the freshness expectation is visible.

Trade-Offs To Explain

A credible recommendation should name trade-offs, not only services:

This is the kind of answer that sounds architectural. It shows that the design is shaped by workload behavior and operating responsibility.

Protection, Lifecycle, and Cost

The data placement map is incomplete without protection and lifecycle decisions.

For this retailer, ask:

• Which data must be encrypted, and who owns the keys?

• Which data needs point-in-time recovery?

• How often are restores tested?

• How long must orders, payments, audit records, and customer data be retained?

• Which S3 objects should move to infrequent access or archive classes?

• Which derived systems can be rebuilt instead of backed up like source systems?

• How are data access, schema changes, and deletion requests audited?

• Which teams own cost for storage growth, indexes, analytics queries, and backups?

These questions often reveal hidden architecture work. A diagram with six data services is easy. A recoverable, governed, cost-aware data platform is harder and more valuable.

Common Mistakes

• Giving one database answer for every data problem.

• Treating the search index, cache, or analytics store as the source of truth.

• Ignoring reconciliation between source systems and derived views.

• Designing for peak scale while forgetting backup, restore, lifecycle, and deletion.

• Putting images or large blobs directly into a relational database without a strong reason.

• Choosing DynamoDB before defining keys, indexes, and access patterns.

If Someone Asks You

Which AWS data services would you use for an e-commerce platform?

A good answer is:

I would split the platform by data responsibility. Product images and static assets fit S3. Orders and payments often fit Aurora or RDS because transactions, auditability, and consistency matter. Known high-scale access patterns such as carts, sessions, or catalog read models may fit DynamoDB. Product search can use OpenSearch as a derived index. Analytics can use Redshift or data lake patterns on S3. ElastiCache can help with hot reads. Then I would define backup, restore, encryption, retention, lifecycle, ownership, freshness, and rebuild rules for each store.

What You Should Remember

The best data architecture is a responsibility map, not a single database name.

Questions to Check Your Understanding

1. Which e-commerce data should usually be treated as source-of-truth?

2. Which data stores are likely derived or rebuildable?

3. How do backup and lifecycle decisions change long-term cost?