Your external tools do not tell you when something changes. You have to go check. Manually. Over and over.
Someone on your team refreshes a dashboard 15 times a day to see if that third-party report is ready.
Your data from external platforms is always hours behind because you only sync it when someone remembers to click a button.
Some systems simply do not push updates to you. Your only option is to ask them repeatedly until the answer changes.
BEGINNER - A foundational pattern for integrating with systems that cannot push updates to you.
Polling is what happens when you cannot get a push notification. Instead of waiting for the system to tell you something changed, you ask it repeatedly on a schedule. Every 5 minutes, every hour, every morning at 6 AM. You check, it responds, and you act on what you find.
This is how you stay synchronized with systems that were not built to notify you. Your accounting software does not ping you when a payment clears. Your project management tool does not alert your other systems when a task completes. So you poll. You ask "anything new?" over and over, and when the answer finally changes, you process it.
Polling is not elegant, but it is reliable. When you have no other way to know that something changed, scheduled checks ensure you eventually find out.
Polling solves the universal problem of staying current when nobody tells you things have changed. Every business has external systems that hold data hostage until you go ask for it.
On a schedule, your system asks an external source "what is the current state?" It compares the response to what it knew before. If something changed, it triggers downstream actions. Then it waits and asks again later.
Set a polling interval, start the simulation, and watch. The external system will complete at a random time. Your polling job will eventually detect it.
Polls made: 0
Check at regular intervals
The simplest approach: check every N minutes regardless of what you find. Easy to implement, predictable load on the external system, but may waste resources polling when nothing has changed.
Slow down when nothing changes
Start polling frequently. If nothing changes, gradually increase the interval. When something does change, reset to frequent polling. Balances responsiveness with efficiency.
Poll based on expected change patterns
Poll more frequently during business hours, less at night. Poll immediately after actions that typically cause changes. Use context to predict when changes are likely.
Your external reporting platform does not send notifications. A scheduled job polls every 30 minutes, checking the report status. When it finally changes to "complete", the system downloads the data and triggers the review workflow. Without polling, someone would have to manually check until they got lucky.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
You set your polling interval to every 10 seconds because you wanted "near real-time" data. The external API blocked your integration after 2 hours. Now you have no data at all, and the vendor is asking why you made 8,000 API calls in a single morning.
Instead: Start with conservative intervals (5-15 minutes for most use cases). Only poll more frequently if you have confirmed the API supports it and you actually need that responsiveness.
Every poll fetches the full dataset and processes it, even when nothing changed. Your system spends 90% of its time reprocessing identical data. Your API costs are 10x what they should be, and your database is churning on pointless updates.
Instead: Use ETags, last-modified timestamps, or change tokens to detect when nothing has changed. Skip processing entirely when the response has not changed since the last poll.
Your polling job crashes mid-run. When it restarts, it has no idea what it already processed. It either skips records (data loss) or reprocesses everything (duplicates). Neither outcome is acceptable.
Instead: Track the high-water mark: the timestamp or ID of the last successfully processed record. On restart, resume from that point. Store it durably, not just in memory.
You have learned when to use polling and how to do it efficiently. The natural next step is understanding the trade-off between synchronous and asynchronous handling, which determines how your system responds after detecting changes.