T

Stéphane Tailland 613de34bd2 Stop caching reads on a read-write API

The proxy cache held every GET on the whole service for 60 seconds, and these
APIs accept writes. Kong's proxy cache has no invalidation on write: a POST
that changes a product passes through the same gateway, and the gateway goes on
serving the value it captured before it, for up to a minute, with nothing in the
response saying so.

It produced a real wrong answer. An agent woken by a stock event read the figure
from before that event and reported, in one sentence, "68 in stock, above the
threshold" and "it crossed the threshold, from 68".

The manifest is kept, unreferenced, carrying the reason — so reinstating it is a
decision rather than a rediscovery.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-31 08:26:25 +02:00

dev

feat(mcp): cap read volume per caller identity

2026-08-29 18:05:48 +02:00

kong

Stop caching reads on a read-write API

2026-08-31 08:26:25 +02:00

.gitignore

first commit

2026-08-23 14:39:25 +02:00

openapi.yaml

Add the OpenAPI spec for the customers domain

2026-08-26 18:28:25 +02:00

README.md

docs: follow the token-exchange broker rename

2026-08-29 07:52:56 +02:00

README.md

customers-api

Kong routing/policy layer for the customers slice of classic-models-api (see /Users/stephanetailland/git/classic-models-api), split out per the DDD decomposition in ../kong-konnect-deployment-strategy.md. The backend itself stays a single monolith — only Kong does the domain split. Same role as ../catalog-api plays for catalog, structure deliberately mirrored.

REST only for now (kong/rest/) — 8 routes covering Customer plus its orders/payments sub-resources (cross-domain reads, same backend). No MCP surface yet, unlike catalog-api — add one (kong/mcp/, a mcp-customers Keycloak audience/client-scope, an entry in dataplane-customers's JWT_AUDIENCE_WHITELIST) the same way if/when this domain needs an MCP entry point.

Route	Method	Backend path
`/customers/v1/customers/`	GET, POST	`/classic-models/api/v1/customers/`
`/customers/v1/customers/{customernumber}/`	GET, PUT, PATCH, DELETE	`/classic-models/api/v1/customers/{customernumber}/`
`/customers/v1/customers/{customernumber}/orders/`	GET	`/classic-models/api/v1/customers/{customernumber}/orders/`
`/customers/v1/customers/{customernumber}/payments/`	GET	`/classic-models/api/v1/customers/{customernumber}/payments/`

Auth

openid-connect on the REST service, audience_required/token-exchange target = classic-models-api (BACKEND_AUDIENCE). Unlike catalog-api, there's no MCP hop minting an intermediate customers-api-audience token today — a caller gets one directly via token-exchange-broker (customers-api-audience client scope, added there 2026-08-23) and calls these routes with it; the REST-layer plugin then exchanges that token again to classic-models-api before it reaches the backend, same second-hop pattern as catalog-api's REST layer. IdP is the local Keycloak (https://keycloak.sttlab.local/realms/classic-models) — see ../dataplane-customers/README.md and ../STATUS.md sections 15/16 for why (platform-wide migration off the VPS Keycloak, not customers-specific). consumer_claims/consumer_by map the JWT sub to a Kong Consumer for per-consumer rate limiting, same as catalog-api.

Other policies

Per-consumer rate limiting, response caching (GET/HEAD), audit log (http-log, endpoint still a placeholder — no real log collector in this lab, same caveat as catalog-api).

Structure

Same three-piece dev/ layout as catalog-api: dev/gitrepository.yaml + dev/flux-kustomization.yaml (deploys ./kong into the customers namespace's dev environment, dependsOn dataplane-customers's Gateway Kustomization), dev/externalsecret.yaml (git deploy key), dev/token-exchange-broker-externalsecret.yaml (the broker's client secret). kong/rest/ — service, routes, path-rewrites, auth/rate- limit/cache/audit-log policies and their bindings.

Not deployed yet — blocked on one external step: the gitea repo kong-customers-api.git this dev/gitrepository.yaml points at doesn't exist (https://gitea.sttlab.eu/stt/kong-customers-api → 404 as of 2026-08-23). A dedicated deploy keypair was generated and stored in Vault (kong-v2/customers-api/git-deploy-key) as if it did — once the repo exists and that key is registered as its deploy key, this content needs to be pushed to it, then dev/gitrepository.yaml + dev/flux-kustomization.yaml

the two dev/*externalsecret.yaml files applied to the cluster. kong-v2/customers-api/token-exchange-broker (the broker's client secret, copied from the live local Keycloak) is already stored in Vault and ready.