Interactive diagram · architecture
A user or caller that asks for popular products in a category.
It starts the request and resolves the service through DNS. It then reaches the CDN or Load Balancer.
Public communication can use a REST API, while internal communication can use RPC.
The name lookup at the front of the service.
It receives the client lookup and directs the request to the CDN. The CDN can then handle popular content before the Load Balancer.
DNS is one of the components introduced to address scalability issues.
A content delivery network for popular content.
It receives traffic after DNS and can handle popular content. Requests that continue reach the Load Balancer.
A CDN is added to address scalability issues.
A front door that spreads traffic across multiple Web Servers.
It receives requests from the CDN and passes them to a Web Server. Multiple Web Servers address a scaling bottleneck.
Load balancing and horizontal scaling add components to address bottlenecks.
A reverse proxy that receives the client request.
It receives traffic from the Load Balancer and forwards it to the Sales API or Read API. This keeps the public request path separate from the API servers.
The design adds multiple Web Servers to address bottlenecks.
An API server that records sales activity.
It receives sales traffic from the Web Server and writes its server log files to the Object Store. Those files become input for the Sales Rank Service.
The design stores raw server logs instead of managing a distributed file system.
An API server for the public popular-products request.
It receives the Web Server request and checks the Memory Cache. On a cache miss, it reads the sales_rank data from SQL Read Replicas.
Internal communication can use RPC.
A service that calculates the past week's most popular products by category.
It reads Sales API log files from the Object Store and uses MapReduce. It writes sorted aggregate results to the SQL Write Master–Slave.
The design should discuss SQL or NoSQL use cases and tradeoffs.
A fast store for popular content and its sales rank.
The Read API checks it before SQL Read Replicas. It handles uneven traffic and traffic spikes, while cache misses continue to the replicas.
With the large volume of reads, SQL Read Replicas might not handle all cache misses.
The SQL database that holds the aggregate sales_rank table.
The Sales Rank Service writes the sorted weekly ranks here. The database replicates the data to SQL Read Replicas.
A single SQL Write Master–Slave might be tough at higher write peaks.
Replicated SQL data used for read traffic.
They receive replicated rank data from the SQL Write Master–Slave. They return cache-miss results to the Read API.
The replicas might not handle all cache misses at the large volume of reads.
Durable storage for raw Sales API server log files.
It receives log files from the Sales API and supplies them to the Sales Rank Service. The service uses those files as MapReduce input.
The design can store a limited period in the database and the rest in an object store.
The client resolves DNS, can use the CDN, then reaches the Load Balancer and a Web Server.
The Sales API keeps raw server log files in the Object Store.
The Sales Rank Service uses MapReduce to aggregate and sort category sales, then writes SQL results.
The Read API checks the Memory Cache, then uses SQL Read Replicas for cache misses.
Detail · follows playback, or click any box or step to pin it
Close · follow playbackClick any box for an explanation, or use Next or Play to walk through the four steps.
The client resolves DNS, can use the CDN, then reaches the Load Balancer and a Web Server.
DNS, the CDN, load balancing, and multiple Web Servers address scalability issues.
The Sales API writes raw server log files to the Object Store.
An Object Store such as Amazon S3 avoids managing a distributed file system.
The Sales Rank Service uses MapReduce to sum quantities by category and product, then performs a distributed sort.
The sorted list is written to the sales_rank SQL table.
The Read API checks the Memory Cache and uses SQL Read Replicas on a cache miss.
Popular rank results should be handled by the cache instead of the database.