Medium · 8 steps · ~40 min

Design a product catalogue with search on AWS

Keep one source of truth, and add a search index and a cache that can fail without taking lookups down.

A catalogue serves two kinds of reads: fetching a product by id, and searching by words and filters. A relational database does the first well and the second badly. You will add a search index and a cache around Aurora, and make sure each can fail without losing the others.

Same problem as Product cataloguesMarketplace searchDocumentation search

This lab uses real AWS services. Limits are AWS's documented default quotas; figures AWS does not publish are marked as assumptions on each component. See every source and assumption.

How it works

• Aurora is the system of record. Lookups by id go to ElastiCache first and fall through to Aurora on a miss (cache-aside).
• OpenSearch answers text queries and filters. It is a derived copy, filled by an indexing pipeline, so it is eventually consistent and can be rebuilt from Aurora.
• Requests here split evenly between the two paths, since the model sends traffic to every connected component in proportion to its size.
• Limits come from AWS documentation (default quotas in us-east-1). Where AWS publishes no figure, such as how many requests a container or database handles, the lab states its assumption on the component.

What you'll build

1. Cache-aside lookups at 2,000 requests a second
2. A search index alongside, at 5,000
3. A plan to keep the index fresh
4. A design where losing the index leaves lookups working
5. A search tier that carries twice the traffic
6. Cache stampedes, invalidation and degraded mode

Steps

1. 1Serve 2,000 lookups/s with a cache
2. 2Add search at 5,000 requests/s
3. 3Keeping the index fresh
4. 4Lose the search index
5. 5Double the traffic
6. 6A cache stampede
7. 7Changing a product
8. 8When the cache is down