[andreasarf]

Summary

Third of three Redis PRs, stacked on #15 (lock), which is stacked on #14 (cache). Merge in order #14 → #15 → #16.

RateLimiters uses Redisson RRateLimiter token buckets in Redis, shared by all instances.

• Created and updated. A limiter is created with the configured rate on first use. If the configuration changed, an existing limiter is updated the first time an instance uses it.
• Expiry. Limiters unused for an hour expire from Redis.
• Redis down. Requests are allowed: limiting is a protection, and losing it shouldn't stop the app.

Limit	Default	When exceeded
Calls to one SDLC system (resourceapi.rate-limit.sdlc.*)	10 per 1 s, waiting up to 1 s for a permit	503 + Retry-After, because it's our own limit, not the SDLC system failing. A background sync logs it
POST /api/v2/projects/{id}/sync per project (resourceapi.rate-limit.sync.*)	6 per minute	429 + Retry-After

• SDLC limit. It sits in ExternalProjectService around the real call, so cache hits don't use permits.
• Sync order. The checks run 404 → lock (409) → rate limit (429) → start (503 if no slot). Requests refused anyway don't use a permit, and a rate-limited request releases the lock it took.

Tests (real Redis)

• RateLimitIntegrationTest:
  • the third uncached call to an SDLC system gets 503 + Retry-After and is not sent;
  • permits used by "another instance" limit this one too, and refill after the period;
  • cache hits don't count;
  • a changed rate is applied to an existing limiter;
  • the third sync of a project in a minute gets 429 + Retry-After: 30;
  • 409s don't use permits.
• ProjectSyncBackpressureTest: sync limit raised in that test, because it retries refused syncs and is about the executor.
• Mutation checks. Each was checked to fail with its fix removed: the config update, and the fail-open handling (via CacheUnavailableTest).

Full suite: 103 tests pass, twice in a row.

---

Generated by Claude Code