Skip to content

Independent architecture study

A storefront free to change

Headless E-Commerce Web Store on AWS

Changing a shopfront should not require rebuilding checkout. This independent architecture study separates the shopping experience from commerce services, with shared APIs for different channels and an order queue between checkout and fulfilment.

An independent architecture study based on public AWS guidance. A design exercise, not a client engagement.

Workload
A web store with browsing, checkout and fulfilment
Constraint
Different channels and traffic patterns share the same commerce logic
Approach
A separate storefront, commerce APIs and asynchronous order handling

What makes this difficult

  • Change without disruption

    A storefront redesign can become a backend release when presentation and commerce logic live together, making routine changes harder to isolate.

  • Useful product discovery

    Shoppers need relevant search and suggestions, but each additional capability introduces data dependencies, operating costs and another response to wait for.

  • Checkout meets fulfilment

    The store and the fulfilment system work at different speeds, so an order needs a durable handover between them.

Follow a shopping basket

A shopper reaches a separate storefront, uses shared commerce services and hands an order to fulfilment through a queue.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  1. 01

    Open the store

    Opens the storeShopperServes cachedcontentCloudFrontStores pageassetsS3Routes pagerequestsALBShows thestorefrontFargate

    The shopper reaches CloudFront, which caches content and fetches static assets from S3; dynamic page requests continue through the load balancer to the storefront.

    Illustrative example Illustrative example: a product page combines cached images with the storefront.

  2. 02

    Recognise the shopper

    Shows thestorefrontFargateChecks theshopperCognito

    The storefront uses Cognito to authenticate the shopper before protected account actions, keeping identity checks separate from the services that manage commerce.

    Illustrative example Illustrative example: a signed-in shopper can access their account.

  3. 03

    Find something worth buying

    Shows thestorefrontFargateExposescommerce APIsAPI GatewayRuns commercelogicFargate and LambdaFinds productsOpenSearch

    The storefront calls commerce APIs, and a backend service searches OpenSearch for matching products, allowing product discovery to evolve independently of the page design.

    Illustrative example Illustrative example: matching products appear in the shopping journey.

  4. 04

    Record the checkout

    Shows thestorefrontFargateExposescommerce APIsAPI GatewayRuns commercelogicFargate and LambdaKeeps commercedataDynamoDB

    Checkout runs in a commerce service that reads and writes application data in DynamoDB, so the browser does not become the authority for order records.

    Illustrative example Illustrative example: the backend records the shopper’s order details.

  5. 05

    Hand the order to fulfilment

    Runs commercelogicFargate and LambdaQueues acceptedordersSQS FIFO

    The commerce service publishes an order message to SQS FIFO for the order management system, allowing fulfilment to process work separately from the shopping request.

    Illustrative example Illustrative example: an accepted order waits for fulfilment processing.

  6. 06

    Refresh what the shop knows

    Keeps commercedataDynamoDBImportssupplier feedsMSK

    Supplier catalogue, inventory and order status feeds enter through MSK, updating commerce data so the store can reflect changes arriving from supply chain systems.

    Illustrative example Illustrative example: a supplier stock update reaches the store’s data.

  • Request
  • Data
  • Later, queued
  • Control

The hard part

A consent event has several destinations

A consent sign-up can matter to the store, a campaign system and a content platform. The guidance uses EventBridge to distribute that event asynchronously. Each destination can handle its own work without making the shopper wait for every integration, but the design still needs clear ownership of retries and consent changes.

Captures consentWeb tierDistributes theeventEventBridgeUpdates storedconsentDynamoDBUpdates campaignsPinpointUpdates contenttoolsThird-party CMS
Illustrative: a consent event fans out to independent destinations, without implying that they finish together.

Why this design

  1. Separate presentation from commerce

    Chosen
    Use a Fargate storefront with commerce services behind API Gateway.
    Because
    Shared APIs let the web experience and additional channels use the same commerce logic.
    Cost
    The team must manage service interfaces and deployments instead of releasing a packaged storefront together.
    Reconsider when
    Choose a packaged store when standard shopping flows meet the business need.

  2. Use managed commerce capabilities

    Chosen
    Use the guidance’s managed services for search, recommendations, chat and fraud screening.
    Because
    These services reduce the amount of specialist capability the application team must build.
    Cost
    Each capability adds usage charges, integration work and service-specific behaviour.
    Reconsider when
    Build a bespoke capability when its distinctive behaviour justifies owning the implementation.

  3. Distribute events asynchronously

    Chosen
    Use EventBridge for events that trigger independent downstream work.
    Because
    Campaign and content integrations should not hold open the shopper’s request.
    Cost
    Delayed updates and failed deliveries require monitoring, retries and reconciliation.
    Reconsider when
    Use a synchronous call when the shopper needs the downstream result before continuing.

Cost and operating assumptions

  • Storefront and services

    Fargate charges depend on allocated compute, memory and running time, including capacity kept available between traffic peaks.

  • Data and caching

    DynamoDB capacity and storage sit alongside DAX and ElastiCache costs, so cache savings must be assessed against their running costs.

  • Commerce intelligence

    Personalize training and recommendation requests, plus Fraud Detector predictions, add costs that follow feature usage.

  • Delivery and integration

    Content delivery, API traffic, event distribution and order messaging add usage-dependent charges across the shopping journey.

Assumptions behind the numbers

The supplied guidance provides no monthly total for this architecture; pricing depends on usage, region and options, including cache capacity and enabled commerce features.

How it stays reliable

  • Spread the web workload

    The load balancer distributes requests across web targets in multiple Availability Zones, reducing dependence on a single zone.

  • Treat caches as copies

    Design cache expiry and invalidation around product and inventory freshness, keeping authoritative records in the application data store.

  • Protect the order handover

    SQS FIFO provides the ordered handover; design fulfilment consumers to handle retries without repeating business effects.

  • Plan recovery explicitly

    Configure recovery objectives and restore procedures for the selected services, rather than treating managed infrastructure as a complete recovery plan.

When this is a poor fit. A poor fit for a small shop whose catalogue and checkout needs are already covered by a packaged commerce platform.

Full technical detailThe numbered AWS flow, every service and the Well-Architected notes.

How the AWS guidance describes it

  1. Route 53, CloudFront and AWS WAF. Customers arrive through different channels; Route 53 resolves the hostname, CloudFront routes and caches requests, and WAF protects against common exploits and bots.
  2. Amazon Cognito. The web application uses Cognito to authenticate and authorise access to backend APIs.
  3. Amazon S3. S3 stores and serves static assets, including images and videos.
  4. Application Load Balancer. The load balancer distributes frontend traffic across web tier targets in multiple Availability Zones.
  5. Amazon API Gateway. API Gateway exposes backend microservices as RESTful APIs for the web tier and mobile application.
  6. AWS Fargate, ElastiCache and DynamoDB. The headless web tier runs on Fargate, caches content and API responses in ElastiCache, and persists sessions and frontend configuration in DynamoDB.
  7. Fargate, Lambda, DynamoDB, DAX and ElastiCache. Stateless backend microservices handle commerce functions, with DynamoDB for application data, DAX for query caching and ElastiCache for microservice responses.
  8. Amazon EventBridge. Web and application tiers emit events for asynchronous consumers, including consent updates distributed to DynamoDB, Pinpoint and external content and marketing systems.
  9. Amazon EFS. Both tiers share common code and files, including configuration, JavaScript, CSS and JSON templates, through EFS.
  10. Managed commerce services. OpenSearch supplies search, Personalize supplies recommendations, Pinpoint supports campaigns, Location supports location features, Fraud Detector screens abuse and Lex V2 provides chat.
  11. Amazon SQS FIFO. Order messages pass through an SQS FIFO queue to the order management system for processing and fulfilment.
  12. Amazon MSK. MSK supports ETL for product and catalogue feeds, near real-time inventory and order status from supply chain systems.
  13. Third-party services. External services integrate with the application to provide additional business capabilities.

Well-Architected

Operational Excellence
Managed and serverless services transfer infrastructure maintenance work to AWS.
Security
TLS, WAF, Shield, encryption at rest and fine-grained permissions provide complementary protections.
Reliability
Core compute spans Availability Zones, while service recovery settings must match the workload’s recovery objectives.
Performance Efficiency
CloudFront, ElastiCache and DAX provide caching at different tiers as request volumes change.
Cost Optimisation
Usage-based services and layered caching reduce unnecessary provisioning and repeated data access.
Sustainability
Serverless compute and supported Graviton choices help align resource use with demand.