CONCEPT Cited by 1 source
Client-middleware interception¶
Client-middleware interception is the use of a producer-side middleware chain — code that runs in the caller's process at the moment an operation is initiated, before it crosses a transport boundary — as the enforcement point for cross-cutting operational gates (feature flags, quota checks, kill switches, rate limits, auth enrichment).
The distinction¶
Many frameworks split middleware into two symmetric chains that wrap transport:
- Client middleware — runs in the sender process when something is dispatched. Sees the request before it leaves.
- Server middleware — runs in the receiver process when something arrives. Sees the request after transport.
The two chains operate on different processes and at different points in time. Installing enforcement at the client chain short-circuits before the request is transmitted; installing it at the server chain short-circuits after transmission (but before business logic).
Why producer-side matters for kill switches¶
For async-job frameworks like Sidekiq,
the canonical structural question is: when an operator wants
to disable InvoiceJob, should the gate sit at enqueue
(caller side, before the job is written to the store) or
dequeue (worker side, before perform runs)?
- Enqueue gate (client middleware): jobs never reach the
store. No garbage accumulates. Callers get a structurally
visible
falsereturn. Doesn't require flushing the store to stop future jobs. - Dequeue gate (server middleware): jobs accumulate in the store until the flag is unset or an operator flushes manually. Workers skip them cheaply, but the backlog is real.
The client-middleware variant is usually the right answer for kill-switch behaviour because it prevents backlog accumulation. The server-middleware variant is better for cases where you want to observe the job attempts while skipping their execution (debugging, dry-run).
Seen in¶
- sources/2026-04-21-planetscale-how-to-kill-sidekiq-jobs-in-ruby-on-rails —
canonical wiki introduction. PlanetScale's
SidekiqMiddleware::SidekiqJobsFlipperruns on the Sidekiq client chain (config.client_middleware), checks a Flipper feature flag per worker class, returnsfalseto short-circuit enqueue if set. Load-bearing choice: enqueue gate, not dequeue gate, so disabling a job prevents backlog accumulation automatically.