A saved-vehicle list that has to survive the vehicle changing under it

A shopper saves a handful of vehicles, comes back a week later, and expects the list to still make sense. Meanwhile the inventory has moved on: vehicles sell and prices change. A saved list that stores a snapshot of each vehicle is out of date within days.

myGarage stores an advertisement ID against the user instead of the vehicle’s details. A price alert keeps the price from when the alert was set next to the current one, so the comparison stays live. When a vehicle sells or is withdrawn, the garage handles it the way a normal browsing session would, because nothing in the record depends on the vehicle still existing.

On Tadvantage each dealer has its own WordPress site, but a shopper’s garage has to follow them from one dealer site to another on the same platform. So the garage tables (saved vehicles, viewing history, price alerts, and a user record keyed to the platform’s VMS identity) live in their own AWS RDS database, reached through a singleton connection, instead of in any one dealer site’s WordPress tables. That one decision is what makes the rest of the feature possible. Without it, a garage would be stuck on whichever site the shopper landed on first.

A Node.js service reads the alerts table, compares each stored price with the current price from the platform’s vehicle-management service, and sends a bilingual HTML email when a watched vehicle drops, with unsubscribe handling and monitoring for failures. The front end is Vue inside Tadvantage and the back end is Node, sharing one database so there’s only ever one source of truth for a price. I built this with a colleague.

Nobody instrumented save, remove and viewed events, so I can’t tell you how many shoppers used it. It’s the same gap I name in the Tadvantage case study. The design holds up, but the adoption data was never collected, and next time I’d set that up before shipping.