foundations
Push vs pull
9 min read
Fully authored
Who initiates? The choice defines your fan-out topology.
In any messaging system, someone has to start the transfer. If the server initiates, that's push. If the client initiates, that's pull. This choice cascades into fan-out topology, connection cost, and staleness.
Trade-off matrix
| Dimension | Push | Pull |
|---|---|---|
| Freshness | Real-time (<10ms) | Poll interval (typically 1-30s) |
| Bandwidth per event | ~50 bytes | ~500 bytes (HTTP headers per poll) |
| Connection cost | Persistent per consumer | New connection per poll (or pool) |
| Server load at idle | Zero | N polls/sec × M consumers even when no data |
| Failure mode | Consumer disconnects → messages queued or lost | Consumer down = no impact on producer |
| Backpressure | Complex — need buffers, dropping, retries | Natural — consumer controls pace |
| Best for | Chat, live scoreboards, alerts, LLM streaming | Batch data pipelines, dashboards refresh, config sync |
The senior insight — hybrid is the answer for most systems
Kafka is a masterpiece of hybrid: producers push into topics; consumers pull at their own pace with cursor tracking. This gives you push-latency at the producer side + pull backpressure at the consumer side. Every modern streaming system copies this pattern.
Applied in these systems
Practice what you just read
Every foundation concept has a companion quiz to close the loop.