Work out what a large device estate actually does to a partitioned log: where the load lands, what a synchronised schedule costs, and how much headroom recovery needs.
This is not a broker benchmark. It starts no cluster and makes no claim about broker throughput, latency or capacity — there is deliberately no output here that answers “can my cluster handle it”. What it computes exactly is the partitioner, the schedule and the arithmetic of recovery. Everything runs in your browser; nothing is uploaded.
1. Your estate
Device classes, and what each class publishes. Edit anything.
Class
Key prefix
Devices
Events/sec each
Events/sec
Share
2. Partition skew
Every key is hashed with the partitioner and weighted by its device's real rate. Then one instrument is given a fault and publishes far faster than its class.
What the bottleneck is, and what the average saysThe hash balances keys, not load
Per-partition load
3. Thundering herd
Same devices, same volume of data, three reporting schedules. The chart is events landing in each second of the period.
4. Recovery headroom
A site buffers through an outage and then replays at k times its normal rate while still producing new data. The backlog drains at (k−1) × normal, so it clears in outage / (k − 1).
Buffered events remaining after the site reconnects