E-commerce Platform

A composite case study: a direct-to-consumer online retailer, a few thousand SKUs, global customers concentrated in North America and Europe, low-tens-of-millions revenue growing ~30% a year, six engineers and one ops person. The constraint that shapes everything is operational simplicity — the architecture cannot require running Kubernetes or a custom data pipeline.

The traffic profile is steady with sharp spikes (Black Friday at 20× daily average), checkout availability is targeted at 99.95%, and PCI scope is minimized by never touching raw card data.

The Architecture

The stack is serverless-leaning with managed services everywhere a clear default exists. Edge: CloudFront with WAF fronts everything — /static/* served directly from S3, /api/* through to an ALB. Application: ECS Fargate runs stateless services (storefront, order API, admin) behind the ALB across two AZs, with Lambda for async and scheduled work.

Edge

CloudFront + WAF/static→S3 · /api→ALB

Application

ALB

ECS Fargatestorefront · order · admin

Lambdaasync + cron

Data

Auroraorders, customers

DynamoDBcarts, sessions

ElastiCachehot reads

S3images

Async

EventBridge

SQSper-consumer queues

Lambdaconsumers

Data: Aurora PostgreSQL Multi-AZ is the relational source of truth (orders, customers, products); DynamoDB holds high-volume per-user state (carts, sessions) with TTL; ElastiCache fronts read-heavy product queries; OpenSearch powers search and recommendations. Async: EventBridge as the bus, SQS per consumer, Lambda consumers, SES for email.

Event Flow and the Right Store per Pattern

Checkout writes the order to Aurora in one transaction, then publishes order.placed to EventBridge, which fans out to per-consumer SQS queues — fulfillment, email, analytics, recommendations — each with its own retries and dead-letter queue. A failure in fulfillment does not block email. Payments stay synchronous: payment success is required before order.placed is published, avoiding distributed-transaction ambiguity.

The team matched each store to its access pattern: relational truth in Aurora, per-user state in DynamoDB, hot reads in ElastiCache, search in OpenSearch. They deliberately kept the relational product catalog out of single-table DynamoDB because the model is relational and admin-edited.

Single-Region Now, Multi-Region Later

The platform runs single-Region (us-east-1) with Multi-AZ HA, serving EU customers through CloudFront edge caching — a deliberate fit for a six-engineer team. A second Region is on the roadmap, triggered by a residency contract, EU latency breaching the SLO, or a Region-outage cost case.

The evolution would add Aurora Global Database, DynamoDB Global Tables for customer data (sessions stay regional), S3 Cross-Region Replication, Route 53 latency routing, and per-Region SES and OpenSearch — roughly 1.6× the single-Region cost.