Move Open VSX Rate Limiting to the CDN Edge

# Move Open VSX Rate Limiting to the CDN Edge

Open VSX rate limiting was originally implemented in the application because we assumed the application would see enough traffic to enforce limits accurately.

That assumption no longer holds. Open VSX now runs behind Fastly, and edge caching means many requests may not reach the application. As a result, application-level rate limiting cannot reliably enforce limits for all eligible traffic.

Rate limiting therefore needs to move to the CDN edge.

## Desired Outcome

Eligible Open VSX requests are evaluated at the Fastly edge before they reach the application.

The edge service should:

- identify customers by rate-limit token where possible;
- fall back to IP range when no token is available;
- apply the customer’s active rate-limit configuration;
- return `429` responses for requests above the allowed limit;
- keep commercial rate-limiting logic out of the open source Open VSX application.

## Delivery Plan

### Phase 1 — Staging Prototype

**Target:** End of July
**Goal:** Validate the core Fastly Compute approach on staging.

Expected work:

- Create a Fastly Compute service for Open VSX rate limiting.
- Route staging traffic through the service.
- Identify customers by token and IP range.
- Sync customer configuration from Open VSX to Fastly.
- Validate counter behaviour at the edge.
- Confirm how extension downloads should be handled.

### Phase 2 — Production Shadow Mode

**Target:** End of August
**Goal:** Run the edge service in production without blocking traffic.

Expected work:

- Deploy the Fastly Compute service to production with it's enforcement disabled.
- Add response headers showing the rate-limiting decision that would have been made.
- Compare edge decisions with current application-level behaviour.
- Validate customer identification against production traffic.
- Start processing Fastly logs for customer usage reporting.
- Build Grafana dashboards for visibility and validation.

### Phase 3 — Production Enforcement

**Target:** September, gated on Phase 2 validation
**Goal:** Enforce rate limits at the edge.

Expected work:

- Enable `429` responses from Fastly Compute for traffic above the allowed limit.
- Monitor enforcement behaviour.
- Disable duplicate application-level enforcement once edge enforcement is stable.

### Phase 4 — Customer Dashboard

**Target:** Q4
**Goal:** Move customer management and usage reporting out of the Open VSX application.

Expected work:

- Build a standalone customer dashboard or self-service configuration app.
- Migrate existing customer-facing usage charts to this dashboard
- Move customer configuration management out of the open source application where appropriate.