Skip to main content

Rate-limit stores

REST clients call the RateLimitStore methods to reserve work, observe response headers, and record HTTP 429 penalties. Applications normally pass a store through rest.rateLimitStore rather than calling these methods themselves. Keep each store scoped to one API endpoint and credential. Keys do not include that scope automatically. See REST behaviour.

MemoryRateLimitStore

Import from talos-fluxer or talos-fluxer/rate-limits. new MemoryRateLimitStore(maxBuckets?) defaults to 1,000 bucket and alias entries. The capacity must be a positive integer. See the source. Share one instance across REST clients using the same API and credential:
This coordinates one process. A custom distributed implementation must make reserve() atomic and namespace its state by API and credential. The optional canPipeline(key) hint enables concurrent reads within the REST client’s concurrency bound. Omit it to retain sequential requests on each route. The in-memory store wakes queued reservations when fresh quota arrives and admits one probe after a window expires, avoiding simultaneous unreserved bursts.

IPCRateLimitStore

Import from talos-fluxer/node. Construct new IPCRateLimitStore(port, maxPending?) on the worker side of a Node MessageChannel. Pending RPC capacity defaults to 1,000. See the source. The parent must call serveRateLimits(otherPort, store, maxPending?). That function returns a cleanup callback. close() disposes the store’s listeners; it does not close the underlying port. Pending RPC overflow and a closed coordinator reject with ordinary Error objects. Use the parent and worker examples for port transfer and supervision.