Most dealer feed architectures make a quiet, unexamined assumption: everything syncs on the same schedule. Every 15 minutes, every hour, every 4 hours (whatever the platform vendor set as a default), and every field in the inventory table rides along on that same clock, regardless of what it represents or what it costs to get wrong.
That assumption is worth questioning directly, because it's rarely the right design. A field's sync frequency should be set by the actual business consequence of that field being wrong for a period of time, not by a single blanket setting applied uniformly across the entire inventory table.
Sorting fields by what a delay actually costs
Split inventory fields into tiers based on business consequence, and a much clearer architecture starts to take shape.
Low urgency: description, secondary features, photo ordering
A four-hour sync delay on any of these costs nothing measurable. No sale is lost because a description finished updating at 2pm instead of 10am, or because photo order settled an hour later than it technically could have. Batching these fields on a slower cycle isn't a shortcut or a compromise: for a field in this tier, it's simply the correct design, and building faster infrastructure for it is effort spent solving a problem that doesn't exist.
Medium urgency: mileage, equipment, merchandising changes
These deserve a meaningfully faster cycle than the low tier, since they can influence a shopper's decision more directly. But a short lag here is an inconvenience, not a liability. A shopper seeing slightly outdated mileage for twenty minutes isn't going to feel misled by it, and the field will have corrected itself by the time it matters.
High urgency: price, availability
This is the tier where delay starts to cost real money and real trust. A shopper who acts on a price that already changed, or who reaches out about a car that's already left the lot, isn't experiencing a rounding error. They're experiencing the exact kind of mismatch that erodes confidence in a listing, and by extension, in the dealership behind it.
Critical: sold, wholesale, hidden
This tier shouldn't be governed by a sync schedule at all. It belongs on a fundamentally different kind of pipeline: event-driven, moving from the DMS to an event or API and then to the website, propagating in seconds rather than waiting for the next scheduled batch. There's no acceptable delay window for a "sold" flag, because every minute it's wrong is a minute a real shopper can act on a vehicle that no longer exists to sell.
The consequence of getting this wrong is already documented
This isn't a hypothetical failure mode, and dealerships aren't the only ones who've noticed it. The FTC has sent warning letters to nearly 100 dealerships over what it calls "ghost car listings": advertisements for vehicles that aren't actually available, in many cases because the vehicle was sold and the listing simply never caught up. Consumer reporting has described the exact same pattern from the buyer's side for years: a shopper inquires about a car, is told it's sold, and finds the identical listing still live days or even weeks later, at which point what may have started as an innocent sync delay starts to look, from the outside, like a deliberate bait-and-switch.
Dealer-side forum discussions confirm the underlying mechanism directly, rather than leaving it as speculation. One recurring explanation dealers give for a "sold" vehicle still appearing online is straightforward: the vehicle gets loaded into the DMS and then syncs out to the many services that populate inventory listings, and if the sale isn't reflected back through that same chain quickly, the listing simply doesn't know yet that the car is gone. None of this requires a dealer to be acting in bad faith. A batch sync running every few hours is a perfectly reasonable design choice for a description field. It is not a reasonable design choice for a sold flag, and in most feed architectures, the two are treated identically far more often than they should be.
Why this is engineering thinking with a direct business consequence
It would be easy to file all of this under "just fix the feed," but the actual fix isn't a single technical patch. It's a design decision about which fields deserve which kind of pipeline, made deliberately rather than left to a vendor's default setting. A polling-based batch sync is cheap to build, cheap to run, and entirely appropriate for anything sitting in the low or medium tier. An event-driven push is more work to design and maintain, but it's the only architecture that actually matches the risk profile of the critical tier, and trying to use one architecture for both tiers means either overbuilding for fields that don't need it, or underbuilding for the one field that can't afford to be wrong.
A good inventory architecture doesn't synchronize every field the same way, because not every field carries the same cost when it's wrong. Sold status should be treated like an alarm. Description text should be treated like a newsletter. The two are built to move at completely different speeds, not because one matters more in the abstract, but because to the business, and to the shopper on the other end of the listing, they already do.
Sources
- Jalopnik: FTC crackdown on "ghost car listings," with warning letters sent to roughly 100 dealers.
- Bloomberg: "Inventory Crunch Exposes Dealers' Bait-and-Switch Online Tactics."
- Digital Dealer: "Top Website Problems That Are Costing Dealers Sales," on listing discrepancies as a trust killer.
- DealerRefresh forum: dealers' first-hand explanation of the sold-status delay mechanism.
- Audizine: a comment from an automotive IT professional on the DMS-to-sync chain.
Last updated: September 11, 2026.