Bird
Raised Fist0

Amazon - Product Catalog, Search, Cart, Order Management Pipeline

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Design Amazon - Product Catalog, Search, Cart, Order Management Pipeline
45 min · senior
senior

You are tasked with designing the backend system for an Amazon-scale e-commerce platform serving 50 million daily active users. The system must handle product catalog management, search functionality, shopping cart operations, and a robust order management pipeline. The platform requires strong encryption for sensitive data, offline availability for the cart, and a P99 latency under 200ms for user-facing APIs.

Constraints
  • End-to-end encryption of user data at rest and in transit
  • Offline cart availability with eventual sync when online
  • P99 API latency under 200ms for product search and cart operations
  • Support 50 million daily active users with peak QPS of ~1 million
  • Order pipeline must guarantee exactly-once processing and strong consistency
📋
Guided Steps
1/5
Step 1
Designing the Product Catalog Storage
How would you design the product catalog storage to support fast reads and frequent updates at scale?
💡 Hint
Consider a database optimized for high read throughput and flexible schema for product attributes.
Key Decision
Use Amazon DynamoDB with product_id as partition key and GSIs for category and price range queries - DynamoDB scales linearly with provisioned capacity and supports flexible JSON attributes.
Interviewer Expectation
Mid: Names DynamoDB or similar NoSQL. Senior: Explains partition key choice, use of GSIs for search filters, and why relational DBs like MySQL fail at 50M DAU due to write contention and schema rigidity.
⚠️Common Wrong Answer
Using a relational database like MySQL for product catalog - leads to write bottlenecks and poor horizontal scalability at 50M DAU.
Step 2
Implementing Search Functionality
How would you implement product search to meet P99 latency under 200ms and support complex queries like full-text and faceted search?
💡 Hint
Think about specialized search engines that index product data and support low-latency queries.
Key Decision
Use Elasticsearch cluster indexing product catalog data asynchronously from DynamoDB - Elasticsearch supports full-text search, faceted filters, and scales horizontally for low-latency queries.
Interviewer Expectation
Mid: Mentions Elasticsearch or Solr. Senior: Explains asynchronous data sync from DynamoDB to Elasticsearch via AWS DMS or Lambda, and why direct DB queries fail latency SLAs.
⚠️Common Wrong Answer
Querying DynamoDB directly for search - results in high latency and inability to support full-text or faceted queries efficiently.
Step 3
Designing the Shopping Cart with Offline Support
How would you design the shopping cart system to allow offline usage and sync with the backend when online?
💡 Hint
Consider client-side storage with conflict resolution and backend storage optimized for fast updates and retrieval.
Key Decision
Use client-side IndexedDB for offline cart storage with background sync; backend uses Redis with TTL per user cart for fast reads/writes and durability backed by DynamoDB for persistence.
Interviewer Expectation
Mid: Suggests client caching or local storage. Senior: Details IndexedDB for offline, Redis as fast cache with TTL and write-behind to DynamoDB, and conflict resolution strategies during sync.
⚠️Common Wrong Answer
Storing cart only on backend without offline support - causes poor UX and increased load due to frequent syncs.
Step 4
Order Management Pipeline Design
How would you design the order management pipeline to guarantee exactly-once processing and strong consistency across inventory, payment, and order status?
💡 Hint
Think about event-driven architectures with transactional guarantees and idempotency mechanisms.
Key Decision
Use Apache Kafka with exactly-once semantics for event streaming; order service uses Kafka Streams to process orders atomically, backed by PostgreSQL with serializable isolation for inventory and payment updates.
Interviewer Expectation
Mid: Mentions Kafka for event streaming. Senior: Explains Kafka exactly-once semantics, transactional writes in Kafka Streams, and why eventual consistency or simple message queues like RabbitMQ fail strong consistency needs.
⚠️Common Wrong Answer
Using RabbitMQ without idempotency - leads to duplicate orders and inconsistent inventory.
Step 5
Ensuring Data Security and Encryption
How would you ensure encryption of sensitive user data both at rest and in transit across all components?
💡 Hint
Consider cloud provider encryption features and TLS for network communication.
Key Decision
Enable AWS KMS-managed encryption for DynamoDB and S3 at rest; enforce TLS 1.2+ for all API and inter-service communication; use envelope encryption for sensitive fields in application layer.
Interviewer Expectation
Mid: Mentions TLS and encryption at rest. Senior: Details AWS KMS integration, envelope encryption for PII, and key rotation policies to meet compliance.
⚠️Common Wrong Answer
Relying only on TLS without encryption at rest - exposes data if storage is compromised.
🔌
API Design Challenge
Sketch 3 core RESTful API endpoints for the system: product search, cart update, and order placement.
Hints
  • How does the client send search queries and receive paginated results?
  • How does the client update cart items and handle offline sync?
  • How does the client place an order and receive confirmation with idempotency?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of DynamoDB with appropriate partition keys for catalog scalability
  • Elasticsearch for low-latency, feature-rich search
  • Offline cart support with client-side storage and backend caching
  • Exactly-once order processing with Kafka and transactional DB
  • Encryption at rest and in transit with AWS KMS and TLS
Good to Have - 30%
  • Conflict resolution mechanisms for offline cart sync
  • Use of Kafka Streams for atomic event processing
  • Background asynchronous data sync pipelines
  • Idempotency handling in order placement APIs
Bonus - 10%
  • Key rotation policies for encryption keys
  • Use of Redis TTL for cart session management
  • Detailed API design with idempotency tokens
Anti-patterns to Avoid
Using relational databases like MySQL for product catalog causing write bottlenecks and poor horizontal scaling leading to system slowdowns and outages at 50M DAU.
Querying primary DB directly for search leading to high latency and poor user experience due to lack of full-text and faceted search capabilities.
Storing cart only on backend without offline support causing poor UX and increased load due to frequent syncs and network dependency.
Using message queues without exactly-once semantics causing duplicate orders and inconsistent state, resulting in inventory errors and customer dissatisfaction.
Relying solely on TLS without encrypting data at rest exposes sensitive data if storage is compromised, violating compliance and security requirements.
✅
Model Answer
▼ Reveal

This design outlines a scalable, low-latency, and secure e-commerce backend system for 50M DAU. It leverages DynamoDB for catalog storage, Elasticsearch for search, client-side IndexedDB and Redis for offline cart support, Kafka with exactly-once semantics for order processing, and strong encryption using AWS KMS and TLS.

Key Decisions
  • Use DynamoDB with product_id as partition key to ensure linear scalability and flexible schema support.
  • Implement Elasticsearch for full-text and faceted search with asynchronous data sync from DynamoDB to meet P99 latency under 200ms.
  • Enable offline cart support using client-side IndexedDB with background sync and Redis cache with TTL for fast backend operations.
  • Design order management pipeline using Apache Kafka with exactly-once semantics and Kafka Streams for atomic processing, backed by PostgreSQL with serializable isolation.
  • Enforce encryption at rest using AWS KMS-managed keys and TLS 1.2+ for all API and inter-service communication, plus envelope encryption for sensitive fields.
  • Implement conflict resolution strategies during offline cart sync to handle concurrent updates and ensure data consistency.
  • Use idempotency tokens in order placement APIs to prevent duplicate orders in case of retries.
  • Apply key rotation policies for encryption keys to maintain compliance and security best practices.
  • Amazon DynamoDB for product catalog storage with product_id partition key for linear scalability
  • Elasticsearch for full-text and faceted product search with asynchronous data sync from DynamoDB
  • Client-side IndexedDB for offline cart storage with Redis cache and DynamoDB persistence on backend
  • Apache Kafka with exactly-once semantics and Kafka Streams for order processing pipeline ensuring strong consistency
  • PostgreSQL with serializable isolation for transactional inventory and payment updates
  • AWS KMS-managed encryption for data at rest and TLS 1.2+ enforced for all network communication
  • Use of envelope encryption at application layer for sensitive user data fields
  • Background sync and conflict resolution strategies for offline cart updates

Practice

(1/5)
1. A SaaS platform must ensure strict data isolation between tenants while allowing shared infrastructure. Which component best enforces tenant data isolation at the storage layer?
easy
A. Use a single shared database schema with tenant_id column filtering in application code
B. Use separate database instances per tenant with network-level access controls
C. Use a multi-tenant database with row-level security policies enforced by the DBMS
D. Use a caching layer to segregate tenant data in memory for faster isolation

Solution

  1. Step 1: Understand tenant isolation requirements

    Strict isolation requires preventing any data leakage between tenants, which network-level controls and separate DB instances provide.

  2. Step 2: Evaluate options for isolation guarantees

    Use a single shared database schema with tenant_id column filtering in application code relies on application filtering, prone to bugs; Use a multi-tenant database with row-level security policies enforced by the DBMS depends on DBMS features that may be complex and less secure; Use a caching layer to segregate tenant data in memory for faster isolation only caches data and doesn't guarantee persistent isolation.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Separate DB instances + network controls -> strongest tenant isolation [check]
Hint: Separate DB instances isolate tenants physically [check]
Common Mistakes:
2. A web application requires users to authenticate with multi-factor authentication (MFA) before accessing sensitive data. Which component is primarily responsible for enforcing MFA in this scenario?
easy
A. The Database, because it stores user credentials and MFA tokens
B. The API Gateway, because it routes requests and can reject unauthorized traffic
C. The Identity Provider (IdP), because it manages user credentials and enforces MFA policies
D. The Load Balancer, because it distributes authentication requests across servers

Solution

  1. Step 1: Identify the role of the Identity Provider

    The IdP manages user credentials and enforces authentication policies including MFA.

  2. Step 2: Eliminate other components

    The API Gateway routes traffic but does not enforce MFA; the Database stores data but does not enforce policies; the Load Balancer distributes requests but does not handle authentication.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    IdP enforces MFA policies, not routing or storage components [check]
Hint: MFA enforcement belongs to the Identity Provider [check]
Common Mistakes:
3. A distributed system requires generating unique IDs that are sortable by creation time and can be generated independently on multiple nodes without coordination. Which component or technology best fits this requirement?
easy
A. Use ULID or KSUID generators embedded in each service node
B. Use a centralized relational database with auto-increment IDs
C. Use UUID version 4 generated randomly on each node
D. Use a timestamp concatenated with a node ID without collision prevention

Solution

  1. Step 1: Identify requirements for sortable, distributed unique IDs

    Centralized DB auto-increment (A) is a bottleneck and not distributed; UUIDv4 (C) is unique but not sortable; timestamp+node ID without collision prevention (D) risks duplicates.

  2. Step 2: Recognize ULID/KSUID properties

    ULID and KSUID provide time-sortable, collision-resistant IDs generated independently on nodes.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    ULID/KSUID generate sortable unique IDs without coordination [check]
Hint: Sortable unique IDs without coordination -> ULID/KSUID [check]
Common Mistakes:
4. If the vector storage layer loses durability guarantees (e.g., no persistent writes), what exact failure occurs during a node crash?
medium
A. The HNSW index rebuilds automatically with stale data but no data loss
B. Queries return incorrect nearest neighbors due to corrupted index links
C. Recent vector inserts are lost, causing missing search results for those vectors
D. The system falls back to brute-force search with no performance impact

Solution

  1. Step 1: Understand durability impact on vector storage

    Without persistence, recent inserts are lost on crash, but existing index data remains intact.

  2. Step 2: Analyze index rebuild behavior

    HNSW index rebuilds from last persisted snapshot, so it uses stale data but does not corrupt links.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Index rebuild uses stale data; recent inserts lost but no corruption [check]
Hint: No durability -> stale index rebuild, recent inserts lost [check]
Common Mistakes:
5. At 10x scale, which component of a B-Tree index is most likely to become the bottleneck first, and why?
hard
A. The leaf nodes, because they grow linearly and cause large disk I/O for range scans
B. The root node, because it becomes a hotspot due to all searches starting there, causing contention
C. The internal nodes, because their fan-out decreases with scale, increasing tree height drastically
D. The buffer cache, because it cannot hold all index pages, causing frequent page faults

Solution

  1. Step 1: Understand B-Tree root node role

    All searches start at the root node, which must be accessed for every lookup, making it a hotspot under high concurrency.

  2. Step 2: Analyze scaling impact

    At 10x scale, root node contention increases as many threads compete to read/update it, limiting throughput before leaf or internal nodes become bottlenecks.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Root node hotspot causes contention first at scale [check]
Hint: Root node is single entry point, hotspot at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard