# Barkday Amazon and catalog architecture notes

## Launch phase

Use Barkday-owned curated JSON as the main source of truth. Keep Amazon use limited to Special Links.

The public page should not call Amazon catalog APIs directly.

## Recommended public-card fields at launch

- title
- benefit
- category
- tags
- ageAxis
- minAge / maxAge or minDogYears / maxDogYears
- sizes
- chew
- affiliate.url
- affiliate.asin

## Later enrichment phase

Use a server-side service that enriches only selected ASINs.

Recommended workflow:

1. Admin discovers or selects ASINs.
2. Barkday stores those ASINs in its own catalog.
3. A scheduled server job calls Amazon `GetItems` for those ASINs.
4. The job writes reduced fields back into an overlay or cache layer.
5. The front end consumes only Barkday-owned merged output.

## Why `GetItems` should be primary later

- Stable product identity by ASIN
- Batching up to 10 ASINs per request
- Better fit for pre-curated catalog entries
- Lower rate risk than live user-triggered search

## Why `SearchItems` should be admin-only later

- Useful for curation and discovery
- Not ideal as a public runtime dependency
- Easier to burn rate limits if every user hits live search

## Cache notes for later implementation

Keep the front end free of Amazon credentials and avoid client-side product-content caching.

Server-side enrichment should separate:

- low-volatility fields like title or image URL
- higher-volatility fields like offers

Even when you later enrich from Amazon, Barkday's own catalog should remain the ranking and policy layer.