Fan-out tax
The fan-out tax is the per-delivered-copy surcharge some real-time services attach to broadcasts. One publish to a channel with N subscribers produces a bill of N plus 1 messages (one for the publish, one for each delivered copy), rather than 1 message.
Why it matters
The fan-out tax is the single largest line-item driver on broadcast-heavy real-time invoices, and it is the one engineers most often miss until they cross a usage threshold. Pricing pages list a per-message rate. The mechanism that determines how many messages a single broadcast counts as is buried in the limits documentation. The result is that two services with identical-looking per-message rates can produce bills that differ by an order of magnitude on the same workload.
The math compounds in three predictable moments:
- The viral moment. Subscribers grow 10x. Every existing broadcast now fans out across 10x the audience. The bill grows roughly 10x even if publish frequency stays flat.
- The product change. Someone ships presence indicators, typing dots, or cursor positions. These emit broadcasts at human-keystroke frequency, fanned out across every viewer.
- The audit. Finance asks why the line item doubled. The honest answer is that broadcasting to your own users is the priced unit, and the price scales with audience.
How it works
Pricing models that apply a fan-out tax count messages at the delivery layer, not the publish layer. The vendor's documentation typically reads: if one message is published to a channel and 50 clients are subscribed, the message count is 51. One for the publish, 50 for the deliveries.
The same workload under a flat broadcast model counts as one broadcast, regardless of subscriber count. The mechanism is the difference between billing the publisher and billing the fan-out itself.
A simple worked example. A typing indicator emits 5 broadcasts per second while a user types. The room has 500 subscribers.
- Per-fan-out model: 5 broadcasts * 501 = 2,505 billable messages per second per typing user.
- Per-broadcast model: 5 billable broadcasts per second per typing user.
The same code on the same protocol produces a 500x difference in billed volume.
Related terms
- Fan-out is the mechanism. The tax is the surcharge attached to it.
- Broadcast is the unit a flat-billing service prices instead.
- Concurrent connections is the alternative pricing gauge: bill on the connection count, not the delivery count.
See also
- /compare/pusher-vs-vask for a worked-numbers comparison on the same protocol under both billing models.
- /migrate/pusher-to-vask-laravel for the credentials-swap migration that removes the fan-out tax from a Laravel app.
- What is the fan-out tax?
- Fan-out tax is the per-delivered-copy surcharge that some real-time services apply to broadcasts. If you publish one broadcast and the service delivers it to 100 subscribers, the bill counts 101 messages instead of 1.
- Why is it called a tax?
- Because the cost is attached to a dimension the engineer cannot directly control. The publisher emits one broadcast. The subscriber count is set by product growth, viral traffic, or session length. Billing scales with that uncontrollable dimension.
- Which services charge a fan-out tax?
- Any real-time service that counts each delivered copy of a broadcast as a billable message is applying a fan-out tax. The vendor's own documentation usually spells out the math: one publish to a channel with N subscribers counts as N plus 1 messages.
- Is the fan-out tax avoidable?
- Yes, by choosing a service that bills per broadcast rather than per delivered copy. Same workload, different bill mechanic, smaller total.
