Marketplace Watcher

Problem

My fiancée was looking for specific shoes and bags for our wedding, second-hand, at a price worth having. Those listings appear and sell within minutes, and the only way to catch one is to be looking at the exact moment it goes up — which means either refreshing a search all day or not getting them.

The requirement was narrow and real: tell us when something matching a saved search appears, quickly enough to act, and do not tell us the same thing twice.

Approach

A polling watcher with a notification pipeline behind it.

The constraint shaped the design. Requests route through rotating proxies on a plan with a hard 3GB monthly allowance, so bandwidth is the budget the whole thing is built around. That rules out the obvious approach of pulling full pages on a tight loop. Instead the client fetches as little as it can get away with per check, which is the difference between a tool that runs all month and one that exhausts its quota in a week.

PostgreSQL is what makes it usable rather than annoying. Every listing seen is recorded, so a notification only fires for something genuinely new. Without that, a watcher on a busy search is just a machine repeating itself until you mute it.

Discord is the notification surface, chosen because it is where we already were, and because it renders price and image inline — so a listing can be judged from the notification without opening anything.

The target sits behind commercial bot protection, so a naive client gets nothing back. Working within that shaped request pacing and how the client presents itself.

Outcome

It runs, it stays inside its bandwidth allowance, and it found what it was built to find.