Distributed throttle

Share one rate limit across every worker or server by pointing the throttle at a shared store. By default a stitch keeps its throttle counters in the in-memory store, so the rate budget is per process: with pool: 'host' every stitch in that process already pools into one budget per host (see Throttle), but the in-memory store keeps that pooling within a single process — each worker gets its own. Point the throttle at a shared store and one budget spans every worker that uses it.

Example

import { stitch } from 'stitchapi';
import type { StitchStore } from 'stitchapi';

// A shared store — e.g. @stitchapi/redis's redisStore() — see The pluggable store.
declare const sharedStore: StitchStore;

const search = stitch({
    baseUrl: 'https://api.example.com',
    path: '/search',
    throttle: { rate: '10/s', pool: 'host' },
    store: sharedStore, // the budget now spans all workers using this store
});

Options

throttle sets the limits — rate (e.g. '10/s'), concurrency, and pool — while store decides where the counters live. The default in-memory store is single-process, so each worker enforces 10/s on its own and the fleet runs at 10/s × workers. A shared store holds the rate counter every worker increments, so the whole fleet shares one 10/s budget — and grants are even-spaced (about one every 100ms, i.e. window / limit), the same pacing the in-process limiter uses, so attaching a store doesn't turn a smooth limit into boundary bursts. (Concurrency stays in-process; only the rate limit is distributed.)

pool decides what shares a budget: 'stitch' (the default) gives each stitch its own counter keyed by name, while 'host' keys by origin so every stitch hitting api.example.com draws from one budget. Workers share a budget only when they point at the same store and resolve to the same key — same pool, same stitch name or host.

See also