Real-time on platforms: live auctions, live feeds and live status
Key takeaways
- Real-time pays off when many people react to the same thing at the same time or wait for a status change, for example in auctions, live feeds or device states. An application should respond to an input within 100 milliseconds; according to Google, users then perceive the result as immediate.
- Three common methods bring updates from the server to the screen: regular polling, server-sent events for one-way messages and WebSockets for two-way exchanges.
- With bids, the server decides the order. It checks and stores every bid in one indivisible step, so that two simultaneous bids cannot both win.
- Connections drop, and smartphones restrict apps in the background. A good real-time platform restores connections itself, reloads the current state and reaches users outside the app via push notifications.
As of September 2026
A sports car auction on your marketplace has 30 seconds to go. Two buyers bid at almost the same moment, while a third watches in the app on a train. All three should see immediately who is ahead, and in the end there is exactly one winner. This guide explains when a platform needs real-time, how the technology works and what matters for bids, dropped connections and mobile apps.
When does a platform need real-time?
A normal web page shows the state at load time, and anything new appears only after a reload. For product descriptions, price lists or guides, that is exactly right. Real-time pays off when information loses its value quickly or many people react to the same thing at the same time: in live auctions, feeds of ongoing activity, the status of an order or a device, chats and back-office dashboards.
Google describes how fast "immediate" has to be in its older RAIL performance model. If an application responds to an input within 100 milliseconds, users perceive the result as immediate. If it takes longer, according to Google, the sense that action and reaction belong together is lost.
Three ways updates reach the screen
On the web, the browser normally asks and the server answers. For real-time, the server must be able to report changes on its own. There are three ways to do this.
Regular polling: the browser asks at fixed intervals whether there is anything new. This is simple to implement. The Internet Engineering Task Force (IETF) describes the downside in its technical document RFC 6202: the shorter the acceptable delay, the more frequent the requests, and at intervals on the order of seconds this can heavily burden the server and the network. With long polling, the server therefore holds the request open until there is something new.
Server-sent events (SSE): the browser opens a connection over which the server can send messages at any time. According to MDN, Mozilla's developer documentation, data flows only one way here, from server to browser. For live feeds, status displays and dashboards, this is often enough, since user actions use normal requests.
WebSockets: according to MDN, WebSockets open a two-way connection between browser and server over which messages flow without constant polling. The protocol has been standardized as RFC 6455 since December 2011. It fits when much traffic flows both ways, for example with bids, chats or collaborative editing.
Why the order of bids matters
In an auction, besides speed, what matters most is clarity. Suppose the highest bid stands at €80,000 and two people bid €81,000 at the same instant. If the server checks both bids against the old state at the same time, both believe they are the highest bidder, a so-called race condition.
The solution: checking and storing happen in one indivisible step, called atomic. The data store Redis, for example, runs small programs (scripts) that, according to its documentation, execute atomically: while a script runs, all other activity on the server is blocked, and its effects have either not happened yet or have already happened completely. This gives every bid a clear place in the order, and the second bid for the same amount counts as too low.
How much real-time an auction needs also depends on its format. The explanations accompanying the 2020 Prize in Economic Sciences describe the best-known formats:
- English auction: the price rises, and everyone sees the bids. Every new bid has to reach everyone immediately.
- Dutch auction: the price starts high and drops step by step until someone buys. Here, whoever acts first wins.
- Sealed bids: nobody sees the other bids. What is live here is the remaining time and your own status.
In all three cases, the server's clock decides whether a bid came before or after the end, not the clock on a smartphone.
How real-time grows with many users
If a platform runs on a single server, that server sends a new bid directly to all connected users. With several servers, an auction's viewers are connected to different machines, and a bid still has to reach all of them.
This is what the publish/subscribe pattern, or pub/sub for short, is for. One server publishes the message to a channel, for example for a particular auction, and every server subscribed to that channel passes it on to its users. According to the Redis documentation, senders and receivers do not know about each other, which allows for greater scalability. Subscribers receive messages in the order in which they were published.
One detail matters for planning: Redis Pub/Sub delivers each message at most once. If a receiver is not connected at that moment, the message is lost, according to the documentation. To deliver missed events later, you can use stored data streams (Redis calls them streams), in which messages are kept, or reload the current state from the database.
What happens when the connection drops?
Connections drop: in a dead zone, when switching from Wi-Fi to mobile data or when a server restarts. To check whether a connection is still alive, the WebSocket protocol has small control messages called ping and pong: one side asks, the other answers.
With server-sent events, the browser reconnects on its own, according to MDN. If the server gives its messages an identifier, the browser sends the identifier of the last message it received when reconnecting, as defined in the HTML standard (Last-Event-ID). This lets the server deliver exactly what happened in the meantime.
With WebSockets, the application handles reconnecting itself. The RFC 6455 standard recommends delaying the first attempt by a random amount of time and then making the intervals gradually longer. Otherwise, after an outage, huge numbers of devices could return at once and put extra load on the server.
After reconnecting, what counts is the current state: highest bid, remaining time, status. It makes sense to load this state fully from the server first and only then show individual changes.
Real-time in mobile apps
As long as an app is open, real-time works as in the browser. In the background, however, smartphones save battery. According to Apple, an iOS app initially has five seconds for important tasks after moving to the background, and shortly afterwards the system suspends it. In its Doze power-saving mode, Android suspends apps' network access when the device lies still for a while, unplugged and with the screen off.
You therefore reach users outside the app with push notifications through the platform providers' services: the Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM) on Android. Google recommends using FCM instead of your own persistent connection, because all apps share one connection, saving battery. For time-sensitive, user-visible notifications, Google provides high-priority messages that are delivered even in Doze mode.
A notification does not replace a live feed, though. Apple describes push notifications as a way to send small amounts of data to devices, even when the app is not running. iOS treats silent background notifications as low priority without guaranteed delivery, and Apple advises sending no more than two or three per hour. A division of labor therefore makes sense: the notification says "You have been outbid", a tap opens the app, and the app loads the current state live.
In practice
Three platforms from our work show how different real-time can look. For CooleKarren, an international marketplace for luxury cars, we developed a real-time bidding engine based on Redis and WebSockets. The marketplace offers three auction formats (English, Dutch and sealed-bid) plus direct purchase, and bid latency is under 100 milliseconds. Bidding works on the web and in native apps for iOS and Android.
byclaw.io is our own product, an AI shopping agent for WhatsApp, Claude, ChatGPT and the web. A live feed there shows what the agents are doing right now. Anyone who puts a product on the watchlist is notified as soon as the price drops.
On the booking platform we developed for Wasserplasma Experience, real-time happens not in the browser but on site: the device unlocks for exactly the booked session, and the back office sees continuously whether a paid hour actually ran on the device.
Frequently asked questions
Does every platform need real-time?
No. Real-time pays off where many users act at the same time or wait for a status, for example in auctions or chats. Often it is enough to make parts of a platform live and load the rest normally with the page.
What happens when two people bid at exactly the same time?
The server checks and stores every bid in one indivisible step and thereby puts the bids in a clear order. The bid processed first counts. The second is then no longer above the highest bid, and the bidder learns this immediately.
Does real-time also work when the app is closed?
In the background, iOS and Android restrict apps to save battery. Important events then reach users as push notifications through Apple's and Google's services. When someone opens the app, it loads the current state and shows changes live again.
Conclusion
Real-time makes a platform come alive: bids, feeds and status displays appear without anyone reloading. What builds users' trust is a clear order of bids, clean reconnecting and notifications that arrive outside the app as well. If you plan for this from the start, you get live features that grow with your platform.
Are you planning a platform with live features?
Describe your idea in our AI project estimator. You will receive a free estimate by email, and we will get back to you within 24 hours.
Learn more about our services for platforms and marketplaces and SaaS products. Or simply write to us at our email address.
Sources
- Google, web.dev: "Measure performance with the RAIL model", last updated June 10, 2020. https://web.dev/articles/rail
- IETF: RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", April 2011. https://www.rfc-editor.org/rfc/rfc6202
- MDN Web Docs: "Using server-sent events", last modified September 3, 2026. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
- MDN Web Docs: "The WebSocket API (WebSockets)". https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
- IETF: RFC 6455 "The WebSocket Protocol", December 2011. https://www.rfc-editor.org/rfc/rfc6455
- Redis: "Scripting with Lua". https://redis.io/docs/latest/develop/programmability/eval-intro/
- NobelPrize.org: "The quest for the perfect auction", popular science background (Popular information) on the Prize in Economic Sciences 2020. https://www.nobelprize.org/prizes/economic-sciences/2020/popular-information/
- Redis: "Redis Pub/sub". https://redis.io/docs/latest/develop/pubsub/
- WHATWG: HTML Living Standard, section 9.2 "Server-sent events". https://html.spec.whatwg.org/multipage/server-sent-events.html
- Apple Developer: "Extending your app's background execution time". https://developer.apple.com/documentation/uikit/extending-your-app-s-background-execution-time
- Android Developers: "Optimize for Doze and App Standby", last updated August 18, 2026. https://developer.android.com/training/monitoring-device-state/doze-standby
- Apple Developer: "Setting up a remote notification server". https://developer.apple.com/documentation/usernotifications/setting-up-a-remote-notification-server
- Apple Developer: "Pushing background updates to your App". https://developer.apple.com/documentation/usernotifications/pushing-background-updates-to-your-app