🧩
Small, owned services
Each team owns a capability and exposes it through a clear API.
System design · visual guide
How a global shopping system works
Explore the architecture behind a large-scale e-commerce platform—from the moment a shopper opens the app to search, checkout, payment, warehouse fulfillment, and delivery.
✦ Microservices↗ Event-driven◈ Distributed data◎ Built for failure
🧩
Many servicesSmall teams own separate capabilities⚡
Low latencyCache and parallel requests help pages load fast📨
Async eventsBackground work doesn't block checkout🛡️
Failure-readyRetries, timeouts and isolation limit impact01 / The mindset
Design principles
The ideas that shape the system before choosing technology.
🔗
Loose coupling
Services use contracts instead of depending on each other's internals.
🛠️
Design for failure
Timeouts and fallbacks help the rest of the shopping journey continue.
❤️
Customer first
Fast, reliable browsing and checkout are core product features.
02 / System map
High-level architecture
Follow the request from the shopper into the services, data stores, and background workers.
Click any block to understand its jobConceptual flow · not an official internal diagram
Simple mental model: request comes in → services do the business work → data is read or saved → events trigger work that can happen later.
Selected component
Client layer
Where the customer begins the journey.
- Web, mobile and voice interfaces
- Requests travel through the edge and API layers
03 / Components
Layers & key services
Each layer solves a different part of the problem.
Client layer
Where requests startDifferent apps ask for data in formats that suit the device and customer experience.
WebiOS / AndroidVoice
Edge layer
Fast entry and protectionDNS directs traffic; a CDN caches static content closer to shoppers.
Route 53CloudFrontWAF / Shield
Traffic management
Route and protect requestsDistributes requests across healthy instances and applies API routing, authentication, and limits.
Load balancerAPI gatewayRate limits
Business services
The work of shoppingCatalog, pricing, reviews, cart, orders, payment, inventory and identity are separate capabilities.
APIsTeam-ownedIndependent deploys
Data layer
Right store for each jobDifferent services choose storage based on consistency, query patterns, speed and scale.
DynamoDBAurora / RDSS3Cache
Event layer
Work that happens laterQueues and streams separate the order flow from notifications, fulfillment and analytics.
SQSSNSKinesisEventBridge
Analytics & ML
Learn from activityClick and purchase data can support dashboards, fraud signals, demand forecasts and recommendations.
S3 data lakeML modelsForecasting
Physical fulfillment
Software meets the real worldWarehouse systems pick and pack items, shipping systems route parcels and tracking updates status.
WarehouseCarrierTracking
Security & identity
Protect users and servicesLeast privilege, encryption, network isolation, payment controls and auditing reduce risk.
IAM-style accessTLSAudit logs
04 / Follow a real request
What happens when you buy something?
A simplified journey from search to doorstep.
1
Search for a product
The search service finds candidates in its index, ranks them, then enriches results with price, ratings and delivery estimates.
Search index + cache2
Open the product page
A page-composition layer requests product details, reviews, stock and recommendations in parallel. Slow optional data can be skipped.
Parallel calls + timeouts3
Add to cart
The cart service stores the shopper's selected items. Cart availability can be prioritized over perfectly fresh data.
Fast, highly available write4
Validate checkout
Re-check the final price, address, shipping options, tax and inventory before committing the purchase.
Validate before commit5
Place the order
Reserve inventory, authorize payment, check fraud, save the order and publish an OrderPlaced event.
Idempotency + workflow6
Trigger background work
The event can notify fulfillment, email, analytics, recommendations and seller systems without blocking the checkout response.
Queue / pub-sub7
Pick, pack and ship
Systems choose a suitable fulfillment center, coordinate packing and carrier routing, and send tracking updates.
Warehouse + logistics8
Keep status updated
Shipping events update the order journey; the customer can see confirmation and delivery progress.
Events + notificationsWhy idempotency matters: if a customer double-clicks Pay or retries after a network timeout, an idempotency key helps prevent the same payment/order action from being applied twice.
05 / Persistence
Data storage strategy
There isn't one database that is best for every type of data.
| Need | Typical store | Why it fits |
|---|---|---|
| Cart / session | DynamoDB-style key-value NoSQL | Fast key-based access and high availability at scale. |
| Orders / transactions | Relational DB such as Aurora / RDS, or fit-for-purpose stores | Structured records and transaction guarantees where needed. |
| Images / media / backups | Object storage such as S3 | Stores large files separately from application records. |
| Repeated fast reads | In-memory cache such as Redis / ElastiCache | Reduces repeated database work and improves response time. |
| Product discovery | Search index | Supports text retrieval, filters, facets and ranking. |
| Analytics | Data lake + warehouse | Supports large-scale reporting and model training. |
| Relationship analysis | Graph database such as Neptune | Useful for connected relationships such as fraud networks. |
⚖️ Consistency vs availability
✓Browsing / cart: a brief delay in data freshness may be acceptable to keep the experience responsive.
✓Payment / final stock commitment: correctness matters; carefully coordinate writes to avoid double charges or overselling.
🔁 Distributed data basics
✓Replication: keep copies to survive failures.
✓Partitioning: split data across nodes to handle growth.
✓Eventual consistency: replicas may briefly differ, then converge.
06 / Asynchronous work
One event, many consumers
After an order is saved, independent systems can react to the same event.
🧾 Order ServiceSave order + publish OrderPlaced
⟶
📦 FulfillmentChoose warehouse, pick and pack
✉️ NotificationsSend order confirmation
📊 AnalyticsUpdate sales reporting
🛡️ Fraud / Seller systemsCheck risk and notify seller
SQS — queue
One task at a time per consumerBuffers work so a worker can process tasks at a safe pace.
SNS — publish / subscribe
One event, multiple subscribersFans a notification out to multiple independent destinations.
Kinesis / streams
Continuous event dataSupports streaming activity such as click events and analytics pipelines.
Important patterns: consumers should handle duplicate messages safely (idempotency); retries and dead-letter queues help isolate persistent failures. An outbox pattern can keep a database change and its event publication in sync.
07 / Growth and failure
How the system scales and stays available
Scale horizontally, cache aggressively, and assume dependencies can fail.
📈 Scalability toolkit
✓Horizontal scaling: add more instances rather than relying on one bigger server.
✓Stateless services: any healthy instance can handle a request.
✓Multi-level caching: browser → CDN → service cache → database.
✓Sharding / replicas: distribute data and read load.
✓Queues + backpressure: buffer work and protect overloaded services.
✓Precomputation: prepare recommendations and rankings before a request.
🛡️ Reliability toolkit
✓Timeouts: don't wait forever on a slow dependency.
✓Retries + backoff: retry carefully without causing a traffic storm.
✓Circuit breaker: pause calls to a failing service and recover later.
✓Graceful degradation: show the product page even if optional reviews fail.
✓Multi-AZ / cells: isolate failures and limit how many users are affected.
✓Health checks: stop sending traffic to unhealthy instances.
A simple caching path
🌐 Browser cacheReuse assets already downloaded
🌍 CDN cacheServe content near the customer
⚡ Service cacheReuse common, frequently requested data
💾 DatabaseSource of stored application data
08 / Operating in production
Observability, deployment & security
A production system needs to be measurable, safely updated and protected.
Observability
Know what's happeningTrack latency, error rates and throughput; centralize logs and trace a request across services.
MetricsLogsTracingAlarms
Safe deployment
Release in small stepsCI/CD, canary or rolling releases, feature flags and automated rollback reduce release risk.
CI/CDCanaryRollback
Security controls
Protect data and accessUse least-privilege access, encryption, network isolation, secret management and audit trails.
TLSIAMVPCAudit
🔥 Prime Day / Black Friday readiness
✓Forecast demand and pre-scale capacity.
✓Warm caches and load-test critical paths.
✓Buffer background work in queues.
✓Throttle excess traffic and protect checkout.
✓Disable non-essential features if needed.
📉 When a dependency is slow
1Set a timeout so the request has a limit.
2Use a cached or default response when safe.
3Skip optional content to keep the page usable.
4Measure the failure and alert the owning team.
09 / Revision
System design interview cheat sheet
A clear order to explain your design without getting lost in details.
🧭 Explain the design in this order
- Clarify features: browse, search, cart, pay, track, reviews.
- Estimate users, request rate, storage and read/write ratio.
- Draw client → CDN → load balancer → API → services → data.
- Deep-dive into cart, orders, payment, inventory and search.
- Explain scaling, caching, queues, replication and failure handling.
- Discuss trade-offs: consistency, latency, freshness and cost.
🎯 Remember these principles
- Microservices have clear APIs and ownership.
- Choose a data store to fit each service's needs.
- Use asynchronous events for work that doesn't need an immediate response.
- Protect critical actions with idempotency and workflow coordination.
- Expect failures: timeouts, retries, circuit breakers and fallbacks.
- Measure p99 latency, errors and throughput.
Important distinction: This page presents a simplified architecture based on the supplied learning guide and public AWS/system-design concepts. It should not be treated as a verified diagram of Amazon's confidential internal systems.