Bird
Raised Fist0

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

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Gateway

Receives product search request

API Gateway accepts HTTP REST search query from client

Protocol:HTTP REST
BeforeNo active search request for user
AfterSearch request forwarded to Search Service
Search Service

Queries Elasticsearch for matching products

Search Service sends query to Elasticsearch index backed by Product Catalog DB in Cassandra

Protocol:Elasticsearch Query
BeforeSearch Service has received query from API Gateway
AfterSearch results retrieved from Product Catalog DB via Elasticsearch
Cart Service

Adds selected product to user cart

Cart Service updates Redis cache and Cassandra with cart item

Protocol:Redis GET/SET + Cassandra Write
BeforeUser cart does not contain selected product
AfterCart updated with new product in Redis and persisted in Cassandra
Order Service

Receives order placement request

Order Service writes order data to Cassandra and produces Kafka event

Protocol:Cassandra Write + Kafka Produce
BeforeOrder not yet created for user
AfterOrder persisted in Cassandra and order event published to Kafka Queue
Kafka Queue

Queues order event for processing

Kafka stores order event for asynchronous consumption

Protocol:Kafka Store
BeforeOrder event not yet in Kafka
AfterOrder event durably stored in Kafka Queue
Order Worker

Consumes order event and finalizes order

Order Worker processes Kafka event to complete order workflow

Protocol:Kafka Consume
BeforeOrder event pending processing in Kafka Queue
AfterOrder marked complete, downstream systems notified
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP REST
        ▼
┌───────────────┐
│ Search Service│
└───────┬───────┘
        │ Elasticsearch Query
        ▼
┌─────────────────────┐
│ Product Catalog DB   │
│   (Apache Cassandra) │
└───────┬─────────────┘
        │ Query Result
        ▼
┌───────────────┐
│ Cart Service  │
│ Redis + Cass. │
└───────┬───────┘
        │ Redis GET/SET
        ▼
┌───────────────┐
│ Order Service │
│ Cass. + Kafka │
└───────┬───────┘
        │ Kafka Produce
        ▼
┌───────────────┐
│ Kafka Queue   │
└───────┬───────┘
        │ Kafka Consume
        ▼
┌───────────────┐
│ Order Worker  │
└───────────────┘
Design Rationale

This architecture illustrates a vertical flow from client request to order completion. The API Gateway acts as the single entry point, routing search queries to the Search Service, which queries Elasticsearch backed by Cassandra product data. Cart Service manages user carts with a Redis cache for fast access and Cassandra for durability. Order Service persists orders in Cassandra and publishes order events to Kafka for asynchronous processing. The Kafka Queue decouples order ingestion from processing, enabling the Order Worker to consume events and finalize orders independently. This design balances synchronous user interactions with asynchronous backend workflows, ensuring scalability and responsiveness.

Primary Focus

✓

Practice

(1/5)
1. A CDN caches content globally and needs to automatically remove stale content after a fixed duration without manual intervention. Which cache invalidation strategy best fits this requirement?
easy
A. Time-To-Live (TTL) expiration set on cached objects
B. Surrogate keys to selectively invalidate groups of content
C. Manual purge triggered by an admin when content updates
D. Client-side cache control headers only

Solution

  1. Step 1: Identify automatic expiration mechanism

    TTL automatically expires cached content after a set time without manual action.

  2. Step 2: Eliminate manual and selective invalidation

    Manual purge requires human action; surrogate keys target groups, not time-based expiry; client-side headers don't enforce server cache expiry.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    TTL auto-expires stale cache entries without manual purge [check]
Hint: TTL auto-expires cache after set time [check]
Common Mistakes:
2. In the AI Code Assistant request flow, at step 4 the Retriever component queries the vector index with the user's code context embedding. What happens if the vector index is temporarily unavailable at this step?
easy
A. Retriever switches to a relational DB fallback with exact keyword matching
B. Retriever falls back to querying the raw code files directly, increasing latency
C. Retriever retries indefinitely, blocking the entire request pipeline
D. Retriever returns an empty result set, causing the generator to produce generic completions

Solution

  1. Step 1: Understand Retriever fallback logic

    Retriever cannot query vector index if unavailable; raw code files (A) are not indexed for fast retrieval; indefinite retries (C) would block latency budget; empty results (B) degrade quality but not typical fallback.

  2. Step 2: Recognize fallback to relational DB

    System uses relational DB fallback (D) with keyword matching to maintain some retrieval capability under vector index failure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Fallback to keyword DB preserves retrieval under vector index failure [check]
Hint: Retriever falls back to keyword DB if vector index fails [check]
Common Mistakes:
3. A browser needs to resolve a domain name to an IP address but wants to avoid repeated queries to external servers for the same domain within a short time. Which component in the DNS resolution chain primarily handles this optimization?
easy
A. The authoritative DNS server for the domain, which caches recent queries to speed up responses
B. The local DNS resolver (stub resolver) on the user's machine, which caches recent lookups to reduce network calls
C. The root DNS server, which maintains a cache of all domain-to-IP mappings globally
D. The recursive DNS server, which never caches results and always queries authoritative servers

Solution

  1. Step 1: Identify the role of the local DNS resolver

    The local DNS resolver (stub resolver) on the user's machine caches recent DNS lookups to avoid repeated network queries for the same domain within a short time.

  2. Step 2: Eliminate other options

    Authoritative DNS servers provide domain data but do not cache queries for clients. Root servers do not cache all mappings globally and are rarely queried directly. Recursive DNS servers do cache results to improve performance, so The recursive DNS server, which never caches results and always queries authoritative servers is incorrect.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Local resolver caches to reduce network calls [check]
Hint: Local resolver caches recent lookups to reduce queries [check]
Common Mistakes:
4. A real-time analytics system must ingest 1 million events per second and provide near-instant query results. Which component best handles the ingestion to balance latency and throughput?
easy
A. A relational database with strong consistency guarantees
B. A batch processing system that aggregates events every minute
C. A distributed log system like Apache Kafka with partitioned topics
D. A single-threaded in-memory queue to ensure ordering

Solution

  1. Step 1: Identify ingestion requirements

    High throughput and low latency ingestion require a scalable, partitioned system that can handle parallel writes.

  2. Step 2: Evaluate components

    Relational DBs (A) can't handle this write volume with low latency; single-threaded queues (C) limit throughput; batch systems (D) increase latency.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Kafka partitions enable parallel ingestion with low latency [check]
Hint: Partitioned logs scale writes and keep latency low [check]
Common Mistakes:
5. At 10x scale, which component in the SLO error budget tracking system is most likely to become the bottleneck first, and why?
hard
A. The metrics aggregation service, because it maintains stateful counters and cannot shard error budget calculations easily
B. The dashboard visualization layer, because rendering 10x more data overwhelms client browsers
C. The raw event ingestion pipeline, because Kafka partitions can be increased indefinitely without limit
D. The alerting system, because it can batch alerts and scale horizontally without state

Solution

  1. Step 1: Identify stateful components that limit horizontal scaling

    The metrics aggregation service maintains counters and error budget state, which are hard to shard without losing accuracy.

  2. Step 2: Evaluate other components' scalability

    Dashboards (A) are client-side and less critical; Kafka (C) scales well with partitions; alerting (D) can batch and scale horizontally.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful aggregation -> sharding limits -> bottleneck at scale [check]
Hint: Stateful aggregation limits sharding, causing first bottleneck at scale [OK]
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