Skip to content

feat(0190): cancel the key registry, with the measurement behind it - #232

Merged
adamkoot merged 2 commits into
developfrom
feat/0190_key-registry-table-if-still-needed
Aug 20, 2026
Merged

feat(0190): cancel the key registry, with the measurement behind it#232
adamkoot merged 2 commits into
developfrom
feat/0190_key-registry-table-if-still-needed

Conversation

@adamkoot

Copy link
Copy Markdown
Collaborator

Summary

  • Decides task 0190 as CANCEL — its first acceptance criterion asked for a decision with a measurement behind it, not a table. No DDL, no code, no IAM, no integration into 0187/0188/0191; the diff is five .md files.
  • Measured on the production account rather than argued: control plane is 10 rps / burst 40 for the whole account (GetApiKeys/GetApiKey/GetUsage all draw on that one bucket); 14 days of CloudTrail is 961 calls peaking at 12/s with CloudFormation as the top spender, not visitors; one portal key exists and the portal is closed; a cold dashboard load costs four control-plane calls (~1.14 s), two of which are the same GetApiKeys run once by the reveal and once by the usage route.
  • The registry loses to code already in the tree. It could replace only those two listings — AWS holds the credential and the counter — so its ceiling is 4→2, while the in-process cache the usage route already runs takes warm loads to 0. Premise 2 (history) has no customer: 0191 states no stored timestamp is needed. Premise 3 (attribution) holds technically, since ClickHouse is on Hetzner, but puts a durability-critical record on the volume that stalled 11.5 h on 2026-08-13 and still has no free-space alarm.
  • Decisive and structural: 0158/0190's ReplacingMergeTree ORDER BY discord_user_id keeps one row per user, so the next issue would overwrite 0192's revocation row and reset the cap the epic forbids resetting. Building it would hand 0192 a shape that loses 0192's data — written into 0192's notes so the trap is found before the shape is copied.
  • Evidence and two named re-open triggers land in docs/epics/self-service-onboarding.md so this is not proposed a third time (0158 → 0190 → ?). 0194's costing criterion corrected while the numbers were in hand: it described the per-load footprint as two calls; it is four.

0190's first acceptance criterion was a decision, not a table. Measured
against the production account rather than argued:

- control plane is 10 rps / burst 40 for the whole account, non-adjustable,
  and GetApiKeys/GetApiKey/GetUsage all draw on that one bucket;
- 14 days of CloudTrail is 961 calls, peaking at 12/s, and the top spender
  is CloudFormation, not visitors;
- exactly one portal key exists and the portal is closed;
- a cold dashboard load costs four control-plane calls, two of which are
  the same GetApiKeys run once by the reveal and once by the usage route.

A registry could replace only those two — AWS holds the credential and the
counter — so its ceiling is 4 to 2, while the in-process cache the usage
route already runs takes warm loads to 0. It loses to code that is already
in the tree.

Premise 2 has no customer: 0191 states no stored timestamp is needed and
nothing in the epic asks for prior-key history. Premise 3 holds technically,
since ClickHouse is on Hetzner, but puts a durability-critical record on the
volume that stalled 11.5 h on 2026-08-13 and still has no free-space alarm.

Decisive and structural: 0158/0190's ReplacingMergeTree ORDER BY
discord_user_id keeps one row per user, so the next issue would overwrite
0192's revocation row and reset the cap the epic forbids resetting. Building
it would hand 0192 a shape that loses 0192's data.

No DDL, no code, no IAM, no integration into 0187/0188/0191. Evidence and
the two named re-open triggers are in the epic doc so this is not proposed a
third time. 0194's costing criterion corrected while the numbers were in
hand: it described the load as two calls; it is four.
0190's job was not only the verdict but the groundwork for whoever needs
storage next. Cancelling the registry is not a ruling that the epic never
stores anything: 0192 will, and it should not restart the question.

Substrate is settled and recorded as settled: ClickHouse, per ADR 0007,
because this project has no other store in the AWS account and one small
table is the worst possible reason to break that ADR.

Three things are left open for 0192 to decide, written into a new Storage
section there:

- the shape must be append-only, and explicitly NOT 0158's
  ReplacingMergeTree ORDER BY discord_user_id, which keeps one row per user
  and would let an issue overwrite a revoke;
- write access does not exist and is not ours to grant. The api-handler
  reads as prices_reader, SELECT only; those grants are XML-managed in BE's
  services.xml; DDL is an operator action as default over the loopback port;
  and a broad DDL grant for the ingestion writer was already rejected under
  0134. "ClickHouse already stands" is true of the cluster and false of the
  capability, and the grant negotiation is the item with cross-team lead
  time;
- whether the record earns its cost at all, given 0192 is optional for
  Tranche 3 and has a cheaper documented fallback.

Same three summarised in the epic doc beside the cancellation, so the
decision reads as "not now, and here is where it lands" rather than "no".
@adamkoot
adamkoot merged commit 2b5d610 into develop Aug 20, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant