A campaign of N devices is split evenly across W worker shards, each capped at a push-gateway rate limit of R messages/second (this is exactly how FCM/APNs-backed fan-out services throttle senders). A fraction p of attempts fail (offline device, expired token, transient 5xx) and are re-queued on the same shard instead of leaving the system:
ideal time T_ideal = N / (W ยท R)
retry overhead attempts per device โ 1 / (1 โ p)
effective time T_eff โ N / ((1 โ p) ยท W ยท R)
Each simulated tick, every shard drains up to Rยทdt messages from its queue; (1 โ p) of that leaves as delivered, p flows straight back into the same queue. That is why the backlog bars shrink slower โ or plateau โ as the failure slider climbs: more of every processed message re-enters the queue instead of exiting the system.
- Worker shards โ more parallel shards linearly cuts completion time, exactly like adding more sender workers behind a mobile backend's notification service.
- Push rate per shard โ models the per-connection rate limit a push gateway enforces on each sending worker.
- Failure / retry rate โ models unreachable devices and gateway errors; the backlog bars and the streaming particles both slow down as this rises, showing why retry storms are the real scalability risk in fan-out systems, not raw device count.
Particles are a proportional visualization of message flow (density scales with active shard count and current throughput), not a literal one-particle-per-device rendering โ real campaigns push far more messages per second than a screen can draw individually.