How we sync 121000 TRREB listings

On July 26, 2026 our production database held 121,215 active, published TRREB listings — every one of them browsable on tenant sites, with its own photos, its own map pin, and a freshness stamp measured in minutes. This post is the honest tour of how that works, because “we sync the MLS” is a sentence every vendor says and almost nobody unpacks.

The feed is a firehose with manners

TRREB data arrives over a RESO Web API feed — the modern, standardized successor to the old RETS downloads. We never re-download the world. Every record carries a modification timestamp, so our sync keeps a checkpoint per resource and asks one question on each pass: what changed since the last time we looked? On a quiet afternoon that answer is a few hundred records. After a long weekend it can be tens of thousands, and the pipeline has to absorb both without anyone noticing the difference.

Five minutes, forever

The property-sync legs run every fifteen minutes, around the clock, with the image and publish legs on even tighter loops. That number is a product decision, not a technical accident: agents get questions about listings the moment they hit the board, and a site showing yesterday’s price is worse than no site at all. We wrote about what staleness actually costs in listing data freshness — the short version is that portals condition consumers to minutes, so minutes became our bar.

Incremental sync has a failure mode worth admitting: if a checkpoint is ever wrong, you silently miss records. So we do not trust it alone. A nightly reconcile pass walks the full active set from the board, diffs it against ours, and terminates anything the feed no longer claims. Phantom listings — sold homes still showing as active — are how MLS websites quietly rot, and the reconcile leg exists to make that class of rot impossible.

Photos are the heavy half

Listing records are small; photos are not. Every image is mirrored off the board’s servers into our own storage, then converted into WebP derivatives sized for cards and full-screen galleries, and served from our own CDN with immutable caching. We never hotlink the board’s image CDN — that rule has its own post, because it is a compliance line and an engineering one at once. Mirroring runs as its own fleet of workers claiming batches from a queue, with active listings jumping the line so a new listing’s photos land before anyone searches for it.

The completeness gate

Here is the rule that shapes everything else: a listing is invisible until it is whole. Photos mirrored and converted, coordinates resolved, required fields present — only then does the record get its published stamp and appear in search, on the map, and in alerts. The alternative is the familiar broken experience of a card with a grey placeholder where a house should be. We would rather a listing appear ten minutes late and complete than instantly and half-built.

What we watch

A pipeline like this fails quietly if you let it. So the checkpoints, the photo backlog, and the geocode queue all feed dead-man monitors — alarms that fire not when something errors, but when something stops happening. That distinction has caught real problems a normal error tracker would have slept through — a queue that stops draining throws no exception; it just goes quiet, and only a monitor that expects motion notices the silence. Each listing page also states when its data was last refreshed, which keeps us honest in the most public way available: the freshness claim is printed where every visitor can read it. If you are evaluating any vendor’s TRREB data feed setup, ask them what happens when their sync silently stalls. The answer tells you how many times they have lived it.