Every platform that emails you when something happens calls those emails instant. Immediate. Real-time. It is on the marketing page of every job board, every marketplace, every rental portal.
It is never true, and the reason is not that anyone is lying. It is that "instant" describes the moment the platform decides to notify you, and what you actually care about is the moment you can read it. Between those two moments sits a queue of scheduled work, and you can count the hops.
The chain
Here is what a notification email traverses on a platform of any size:
1. Publication. A record is written. The clock starts.
2. Indexing. The record becomes visible to whatever queries it — a search index, a materialised view, a cache warm. On a large site this is asynchronous. Your alert cannot fire on a row the alert system cannot see yet.
3. The matcher. Something has to compare the new record against saved searches. Nobody does this synchronously on write at scale — it is a fan-out over a large table, so it is a job, and a job runs on a schedule.
4. The notification job. Matches become messages: render templates, group into digests, apply per-user frequency caps. Also a job, also scheduled, often deliberately batched so one user does not get nine separate emails in a minute.
5. The email service provider. The message is handed to an ESP via API. This is the fastest hop and the only one that is genuinely near-instant.
6. The send queue. The ESP does not send immediately. It has its own queue, its own rate limits per receiving domain, and a warm-up regime — sending too fast to Gmail is how you get classified as spam, so throttling is a feature.
7. The recipient's mail server. Greylisting exists. Spam analysis takes time. Gmail's own delivery pipeline is a pipeline.
8. The mail client. IMAP IDLE is fast; polling clients check on an interval.
Every hop from 2 to 6 is scheduled work running at a volume measured in hundreds of thousands of messages a day. None of them is malicious, none is badly engineered, and the total is not zero. "Instant" is a claim about hop 1.
You do not need to know any platform's internals to be confident about this. You only need to know that the work is batched, because at that volume it has to be.
The structural alternative
The way to be faster is not to make the chain faster. It is to not have a chain.
Our app runs on the user's own machine and polls the search results page itself — the same page a human would refresh — roughly every 30 seconds. When a new entry appears, the only remaining hop is one email from our own server to one user.
No indexing lag, because we read the rendered page, which is the source of truth for what a visitor can see. No matcher job, because the user's search is the query and there is exactly one of them. No batching, because there is nothing to batch — one user, one machine, one search.
The upper bound on our latency is the poll interval, and it is a number we chose rather than a number that emerges from queue depth under load. That is the real difference: our worst case is bounded by design, theirs is bounded by infrastructure load at the moment your listing happened to appear.
What it costs, honestly
This is not free and it is not always the right architecture.
It is per-user work. A centralised matcher does one pass over a new record for a million users; we do one page fetch per search per user. That is wildly less efficient in aggregate, and it only makes sense because the work runs on hardware we do not pay for — the user's own laptop.
It is polite-scraping work. Polling someone else's page every 30 seconds means jitter, sequential requests, backoff on challenge pages, and a real chance the site changes its markup on you.
And it needs the machine to be awake. A closed laptop polls nothing. A server-side pipeline does not care whether you are asleep.
Fifteen searches per user is our ceiling, because a poll cycle is sequential and has to finish inside the interval. A centralised system has no such limit.
So: strictly worse on efficiency, robustness and scale. Strictly better on the one axis the product is sold on. If latency is not your differentiator, do not build this — build the queue, it is the right answer.
The general lesson
When a system advertises a latency number, ask which event it measures from and which it measures to. Almost always it is the first hop of eight, and almost always the marketing number and the user-perceived number are measuring different things.
Then count the hops. You usually cannot make any single one faster — they belong to other people. Sometimes you can remove all of them.
See the comparison
We worked through this against the specific alert services people use for rental search — what each one's pipeline looks like and where the time goes — at notifio.app/compare/rentbird, with the others linked from notifio.app/compare.
If you would rather measure it than read about it: install the app from notifio.app, point it at the same search you already have an email alert set up for on any portal, and wait for a listing that trips both. The interesting output is the gap between the two timestamps in your inbox.