Rate Limits

Limit Tiers & Quotas

Meridian enforces rate limits at three granularities: per-second burst, per-minute sustained, and per-day absolute quota. Default allocations are determined by the tenant’s plan tier, but enterprise accounts may negotiate custom ceiling agreements through the API contract. Limits apply independently to each API surface — inference, pipelines, telemetry export, and webhooks each maintain isolated counters, ensuring that a batch telemetry flush does not consume headroom reserved for latency-sensitive inference calls.

Sliding Window Algorithm

Meridian’s rate limiting layer uses a sliding window counter backed by a distributed Redis cluster with sub-millisecond replication lag across nodes. Unlike fixed-window implementations, the sliding window eliminates boundary bursts by calculating the request count as a weighted sum of the current and preceding window, proportioned by elapsed time. This approach guarantees that no client can double their effective rate by timing requests at window boundaries, a common exploit in fixed-window systems.

Handling 429 & Backpressure

When a limit is breached, Meridian returns HTTP 429 Too Many Requests with three headers that must be consumed by compliant clients: X-RateLimit-Limit (the ceiling), X-RateLimit-Remaining (current headroom), and Retry-After (seconds until the next available slot). All official Meridian SDKs implement automatic backpressure handling and will surface a typed RateLimitError with the parsed retry duration. Clients that ignore the Retry-After directive and continue issuing requests will have their source IP temporarily deprioritized in the edge queue for 60 seconds.