Skip to content

RFC 089: record the no-cache decision and throttle limits - #174

Merged
annak-k merged 1 commit into
mainfrom
rfc-089-caching-decision
Oct 6, 2026
Merged

annak-k merged 1 commit into
mainfrom
rfc-089-caching-decision

Conversation

@annak-k

@annak-k annak-k commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

Preview

What does this change?

Part of wellcomecollection/platform#6536.

Records the caching decision that followed the Identifiers API load test (results). The RFC proposed an edge cache to keep query volume off the registry, but the test found the registry far from its limit at up to 400 requests a second, and a minting run made no measurable difference at up to 100 requests a second. No cache is placed in front of the API, which also removes the cache-key questions about x-api-key and the idDatabase alias.

  • The Caching section now states the decision, the evidence for it and when to revisit it. The freshness table and ETag description stay, as headers for consumers that keep their own copies.
  • The throttle is described as sharing capacity and limiting cost rather than protecting the database, and the limits are recorded: 10 requests a second with a burst of 20 per external key, and no throttle on the internal usage plan.
  • Open question 1 is marked decided. Its unresolved parts (max-age values, the form of the ETag, and the cost-attribution mechanism) move to a new open question 8, and next step 2 follows them.
  • The stage cache alternative becomes "a cache in front of the API", with why it was not adopted, and remaining references to a cache are removed.
  • rfcs/README.md: the listing table is regenerated for the new purpose wording and date.

How to test

Read the Caching section and open questions 1 and 8 in the preview. .scripts/validate_rfc.py and .scripts/create_table_summary.py --check-readme both pass locally.

How can we measure success?

The RFC matches what is deployed: no cache in front of the API, and the throttle limits in terraform/modules/identifiers/usage_plans.tf in catalogue-api.

Have we considered potential risks?

Documentation only. The decision rests on a test against the previous production registry, which has half production's capacity, with a minter replay that only read. The Caching section names the conditions for revisiting it.

Generated with Claude Code

@annak-k
annak-k requested review from a team as code owners October 6, 2026 14:39
@annak-k annak-k moved this to Ready for review in Digital platform Oct 6, 2026
@annak-k annak-k self-assigned this Oct 6, 2026
@annak-k
annak-k merged commit 7220f2e into main Oct 6, 2026
7 checks passed
@annak-k
annak-k deleted the rfc-089-caching-decision branch October 6, 2026 14:52
@kenoir kenoir moved this from Done to Archive in Digital platform Oct 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Archive

Development

Successfully merging this pull request may close these issues.

2 participants