Local vs Shared Filters Across Many Instances

In one line

Each app instance can hold a local copy (nanosecond lookups, memory × instances, update fan-out) or all instances can query one shared Redis filter (one copy, one network hop per lookup, Redis as a dependency). Choose by filter size, update rate, latency budget and failure behaviour, and often combine them.

0/4 · 0%

Think of it like this

Every employee having a printed phone directory on their desk (fast, but reprinting and distributing updates takes effort) versus calling the central operator (always current, but slower and useless if the operator is on a break).

Key ideas

01
Local: lookups in ~100 ns, no network; memory = filter size × instances (120 MB × 100 = 12 GB fleet-wide); updates must reach every instance (event stream or periodic snapshot); restarts need a fast load path (snapshot + catch-up).
02
Shared (Redis): one copy, updates applied once and visible to all immediately; each lookup costs a round trip (~0.3–1 ms) and Redis load (100K lookups/s is fine for Redis, 10M/s isn't); Redis failure affects every instance.
03
Hybrid: local filter for the hot path, rebuilt from snapshots and updated from Kafka; Redis or the database as the fallback for items newer than the local snapshot.
04
Consistency: local copies are eventually consistent (lag between an insert and every instance seeing it); design so that lag never produces a harmful false negative (fall through to the database for recent IDs, or ensure the filter is updated before an ID is exposed).
05
Decision factors: filter size (can every instance afford it?), update rate (can you fan out updates?), query rate (can Redis handle it?), latency budget, and whether failure should fail open or closed.

Code & diagrams

local-vs-shared.txttext

                     Local copy per instance        Shared Redis filter
Lookup latency       ~100 ns                        ~0.3-1 ms (network)
Memory               size x N instances             size x replicas
Update propagation   fan-out (Kafka, snapshots)     one write, visible to all
Consistency          eventual (lag per instance)    immediate
Restart              must load (snapshot + replay)  nothing to do
Failure domain       per instance                   Redis outage hits all
Throughput limit     CPU of each instance           Redis ops/s on one key/shard

Interview problem

The problem

100 application instances need membership checks

100 instances each serve 5K requests/sec needing a membership check against 200 million IDs that change at 2K inserts/sec. Should every instance keep a local copy, or should Redis hold one shared filter? Analyse filter size, update frequency, latency, availability and memory cost.

Explain it without notes

When would you prefer a shared Redis filter over local copies?

Practice

Redo the analysis for 20 instances, 50M IDs and 100 lookups/s each.

Trade-offs

↔
Local filters trade memory and update plumbing for speed and resilience; shared filters trade latency and a dependency for simplicity.

Done when you can

I can choose local, shared or hybrid filter placement from size, rate and latency requirements.

Command Palette