Push Notification Fan-Out at Scale

Campaign

Notifications queued 300

Fan-Out Shape

Worker processes (W) 4

Per-worker dispatch rate 8 /s

Gateway rate limit (shared) 40 /s

Live Status

0 / 0 delivered

Backlog queued

Effective throughput

0 /s

Elapsed

0.0 s

Gateway-bound?

—

Scaling curve (re-simulated)

Total delivery time vs. worker count — each point is a full re-run of the dispatch simulation, not a formula. Dot marks the current worker slider.

How it works

This is a genuine discrete-time simulation, not an analytic formula plotted as a curve. Every tick, each idle worker pulls one notification off the shared queue and processes it for 1 / per-worker-rate seconds. When processing finishes, the worker must acquire a token from a single shared token bucket (the push-gateway rate limit) before the notification counts as delivered — if no token is free, the worker holds the finished packet and blocks until one is.

per tick:
  refill bucket by rateLimit * dt (cap 1 token)
  finish any worker whose processing timer hit 0 -> "waiting for token"
  waiting workers with a free token -> deliver, consume token
  idle workers with backlog -> pull next item, start processing

theoretical crossover:  W* ≈ rateLimit / perWorkerRate
below W*: total time ≈ N / (W * perWorkerRate)   (linear speedup)
at/above W*: total time ≈ N / rateLimit           (gateway-bound plateau)

The scaling curve on the left is built by re-running this exact tick loop, with a fresh simulated state, once for every worker count from 1 up to 16 — the "genuinely computed" result, not the closed-form line above (that line is only the theoretical prediction the simulation is checked against). At low worker counts every added worker is fully used, so completion time falls roughly in proportion to W. Once W · per-worker-rate passes the gateway's rateLimit, extra workers spend their time waiting for a token instead of processing, and the curve flattens — the plateau always sits at worker count ≈ rateLimit / per-worker-rate, which you can verify by dragging the rate-limit or per-worker-rate sliders and watching the flattening point shift.

Queue → worker (dispatch) Worker → gateway → device (delivery) Worker blocked on rate-limit token