Everyone who bids in an auction is trusting three things: that the price on their screen is the real price, that the clock is the same for everyone, and that the highest bid wins. In a saleroom you can watch the auctioneer keep to that. Online, the software has to do it, for people on different devices and different connections, all at the same time.
A price everyone sees at the same moment
Say one bidder’s screen shows 2,400 and another’s still shows 2,300. The second bidder is now bidding against a price that’s already gone. Their bid fails, or they stop bidding because they think they’ve won.
So a live auction can’t rely on people refreshing the page. Each new bid has to reach everyone watching within a second, along with the new minimum bid and, if it moved, the new end time. To do that, the site keeps a live connection open to every visitor and sends each change as it happens. Some networks block that kind of connection; then the page should fall back to checking for changes rather than sit there showing an old price.
One clock that everyone trusts
Phones and laptops don’t all keep exactly the same time. If each device worked out for itself when an auction ends, two bidders could see two different endings. So the server’s clock decides. The lot opens and closes on server time, and every screen counts down to that moment.
The server should also check the clock again each time someone looks at a lot or bids on it. That way a result is still right even when a scheduled task runs late.
The clock also needs one rule for late bids. You’ve probably seen this one: someone waits until the last second and bids when nobody has time to answer. It feels unfair to everyone else, and it can keep prices down. The usual fix: a bid in the final minute pushes the end back a little, so the others get a chance to respond. Bidding carries on until people actually stop, rather than being cut off by a timer halfway through a contest.
A reserve, and bids taken one at a time
Sellers sometimes have a price they won’t go below. A secret reserve covers that. Bidders only see whether the reserve has been met, never the figure itself, and if bidding stops short of it the lot doesn’t sell.
Then there’s the rule that’s easy to say and hard to get right: two people can’t win the same lot. If two bids arrive at the same instant, the system has to handle them one after the other, so the second one has to beat the first. And if a dropped connection makes someone’s phone send a bid twice, it must only count once. Buyers never see any of this, but it’s what decides whether they trust the site.
What the person running it needs
The person in charge has a different job from the bidders. They need to be able to:
- set up lots with photos, prices and timing;
- fix a mistake while an auction is running, including moving its end date;
- pause bidding if something goes wrong;
- remove the bids of someone who breaks the rules;
- see afterwards who did what.
That last one matters more than it looks: when a bidder asks a question, a record of every change is how you answer it with confidence.
Try it: our auction playground
We built an auction playground to show all of this working. Lots go up with their own end times, bids reach everyone watching straight away, late bids add time, and automatic bidders join in, so there’s always something going on. Nothing is sold and no money changes hands. The workflow page explains the rules and the admin side, and lists demo logins so you can place bids yourself. Try opening the same lot in two browsers and outbidding yourself: you’ll see the updates arrive in both.
For technical readers: the API is Node.js with Fastify and TypeScript, on a MariaDB database. Each bid runs in a transaction that locks the lot, which is what lines bids up one at a time, and a retry key makes sure a repeated bid counts once. Live updates go out over one WebSocket per visitor, with polling as the fallback. The front end is a React and Next.js progressive web app (a web app you can install on a phone).
When you need something like this
Real-time features are worth building when people act on the same information at the same moment. Auctions are one case. Bookings with limited places, live order boards and dispatch screens are others. If your product works like that, you’ll be asking the questions an auction has to answer. Who sees what, and how fast? Whose clock counts? What happens when two people act at once?
Real-time applications like this are part of our custom web application development work, and the API behind them is part of Node.js and API development. You tell us what you want to build. We’ll ask about your users, your business goal and your constraints, then recommend a scope and an approach. Describe your project and we’ll reply by email.
