3 ms·
As a methodology, push is always better than polling. Change my mind.
by joshspankit 6y ago
As a methodology, push is always better than polling.
Change my mind.
- wereHamster 6y agoPush requires more engineering effort to build the server-side of the system. Poll is easier to implement for consumers, and probably also easier to scale for most engineering teams (scaling a central DB is a well understood engineering problem). I agree that push is better overall, but… tradeoffs
- joshspankit 6y agoIn the real world: agreed on there being tradeoffs. But as a methodology?
- ubertaco 6y agoI mostly agree with you, but having spent a good part of my career dealing with data integration patterns, I'm all too familiar with the problem of missed messages from the consumer (or failed-to-send messages from the producer) that results in something downstream being in an incoherent state. The simplest fix for that incoherent state is often to also poll periodically, or something similar.
- joshspankit 6y agoSounds like it would share solutions with the “two generals problem”.
- jeffbee 6y agoPush can cause thundering herds while TTL expiration should occur uniformly over time.
- jedberg 6y agoYou need both for a robust system. Simple example: On system startup, a system should poll for the current config. It should keep polling every few minutes to verify that it hasn't missed any pushes. But it should also register for push notifications of config changes so it can get them faster. It should also renew its subscription if it finds that it missed an update during poling.