Protect the administration API with request rate and concurrency limits

[carndog]

Outcome

Protect the administration API and its database from excessive inbound requests, accidental client loops and bursts, while retaining the existing Entra authentication and owner authorization boundary.

Use ASP.NET Core's built-in rate-limiting middleware in the API adapter. Keep HTTP throttling concerns out of Domain and Application handlers.

Target iteration

Iteration 3, M1 — Configuration Foundation. Deliver after the revision API in #45 as part of completing the configuration foundation. #32 remains the next implementation task.

Project planning: Ready; priority Next; size M.

Acceptance criteria

Policies and resource protection

• Configure inbound request-rate policies for administration endpoints, including both the existing create/read slice and the revision endpoints delivered by Expose the monitoring-rule revision lifecycle through the API #45
• Partition authenticated caller limits by a stable, trusted identity from the deployed Easy Auth boundary; do not trust arbitrary client-supplied identity or forwarding headers
• Apply separate configurable read and write budgets, with more restrictive write limits, and ensure new administration endpoints inherit protection by default
• Add an API-instance-wide concurrency limit across protected administration requests to bound simultaneous handler/database work, in addition to per-caller request-rate limits
• Keep the waiting queue disabled or explicitly small and bounded; honour cancellation and release concurrency permits on success, rejection, cancellation and failure
• Bind limits to validated configuration, document safe synthetic example values and tune the deployed policy using measured legitimate traffic
• Preserve the existing Entra authentication and owner allowlist; missing or untrusted identity must not create a bypass or an unlimited partition

HTTP and probe behaviour

• Reject excess requests before invoking Application handlers or performing database work, returning HTTP 429 with consistent public-safe Problem Details
• Return Retry-After when the selected time-based limiter can estimate retry time; do not invent a retry time for concurrency-only rejection
• Define policies explicitly for /health, /version, /auth-check and /health/database; keep normal liveness/deployment probes reliable and prevent health traffic sharing an administration caller's budget
• Retain the database-probe key check and give database readiness checks bounded access so they cannot bypass database resource protection
• Keep anonymous rejection and authenticated-owner access behaving as intended, with no new public administration access

Observability and verification

• Record low-cardinality accepted/rejected counts and useful policy/endpoint-group information through the telemetry foundation from Add Application Insights and App Service deployment diagnostics #36, without recording tokens, raw caller identities, sensitive payloads or query strings
• Add focused API/integration tests for allowed traffic, burst rejection, recovery after replenishment, read/write policies, caller isolation and the shared concurrency ceiling
• Verify rejected requests do not call handlers/stores; verify permit release on exception/cancellation and continued probe availability
• Provide a repeatable bounded local test using synthetic requests; avoid uncontrolled traffic generation against Azure
• Document that the initial limiter state and concurrency budget are per application instance and reset on restart; record scale-out implications and require a shared/edge enforcement design before claiming a deployment-wide quota
• Document configuration, endpoint coverage and how to inspect throttling telemetry

Dependencies and related work

• Authenticated administration API: Create the authenticated watched-instrument API vertical slice #4
• Entra ID Easy Auth and owner authorization: Protect the deployed API with Entra ID Easy Auth #38
• Telemetry and sanitisation foundation: Add Application Insights and App Service deployment diagnostics #36
• Planned delivery sequence and revision endpoint coverage: Expose the monitoring-rule revision lifecycle through the API #45
• Outgoing market-data throttling remains in Implement the read-only eToro market-data adapter and sampling policies #12
• Outgoing broker/executor throttling remains in Add executor rate limiting, concurrency controls and a manual kill switch #18

Out of scope

• Changes to Domain rules, revision semantics or database optimistic concurrency
• Price-provider and broker request limits or retries
• Paid API Management, Front Door/WAF or other new Azure resources
• Distributed quota storage and multi-instance coordination
• Comprehensive DDoS mitigation, public registration, customer tiers or billing quotas

Application rate limiting is an additional resource-protection control; it does not replace authentication, authorization or edge/network DDoS protection.

Reference

• ASP.NET Core rate-limiting middleware