Protecting a High-Traffic Product Catalogue API from Overload

Problem/Feature Description

An e-commerce platform serves a Fastify product catalogue API that receives heavy, bursty traffic. During peak shopping events the service has experienced two recurring problems.

The first problem is thundering herd on popular products. When a product goes viral (e.g. a flash sale announcement), hundreds of concurrent requests arrive within milliseconds, all of which hit the database for the same product record. The database buckles under the load even though the data being fetched is identical for each request. Introducing a simple TTL cache helped somewhat, but during the burst window before the first request completes, all the subsequent requests still reach the database simultaneously.

The second problem is event loop saturation. Under sustained load the Node.js event loop latency climbs above one second. At that point the API is technically still running but is responding so slowly that clients time out and retry, making the situation worse. The ops team wants the service to detect this condition and shed incoming requests with an explicit 503 response rather than letting the event loop spiral.

Your task is to build a production-hardened version of the product catalogue API that addresses both problems. The service must include at least three routes: list all products (GET /products), fetch a single product by ID (GET /products/:id), and search products by category (GET /products/search?category=...). For the purposes of this implementation, the "database" can be an in-memory array of product objects — no external database connection is needed.

Every route must return a well-defined response shape. The agent must avoid returning untyped JSON responses.

Output Specification

Produce the following files:

• package.json — type: "module", with all required dependencies and a start script
• src/app.ts — Fastify application factory with load-shedding and caching configured. Export buildApp()
• src/plugins/catalogue.ts — a Fastify plugin that registers the three product routes. The expensive "database" lookup for individual products and search results must go through the caching layer rather than being called directly in the handler
• src/data/products.ts — the in-memory product data (at least 5 sample products with id, name, category, price, and description fields)
• performance-notes.md — a short document explaining: which package is used for load shedding and what thresholds are set, which package is used for request deduplication/caching and how it prevents thundering herd, and why response schemas are defined on every route