Context
Live Status was a FURIA product delivered through WhatsApp, built for following matches without watching a stream. In practice, it worked like a modern sports radio feed: instead of video, the system pushed game events, context, and media through WhatsApp.
The idea made sense from day one, so the hard part was never the concept itself. The hard part was making it feel live.
Where this kind of system usually goes wrong
When I joined the project, Live Status already existed. It had a foundation, a working flow, and a clear product shape, but the “real-time” part was still lagging by minutes. That kind of problem is deceptive because nothing looks obviously broken: messages go out, the system responds, and technically everything works.
But once the information arrives minutes late, people are no longer following along. They are getting a recap. That changes the product completely because its value comes less from the raw information than from the feeling of “I’m following this as it happens.”
Once that feeling is gone, the product can still be useful, but it turns into something else.
The shift
The turning point was not technical. It came from reframing the problem. We were not trying to tell users what had happened; we wanted them to follow it as it happened.
That sounds subtle, but it changes the standard. Once you think about it that way, you stop treating the system like a message delivery service and start treating it like an event stream.
In real-time systems, being fast most of the time is not enough. If the user notices lag, bad ordering, or confusing context, the experience has already started to fall apart.
From polling to events
The earlier architecture was built around polling, with cron jobs checking external sources to figure out whether anything had changed. Polling is delayed by design because there will always be a gap between an event occurring and your system noticing it.
So we stopped asking and started reacting. The system moved to a direct WebSocket event stream. Instead of repeatedly checking whether something new had happened, it received each event as the match unfolded.
Events were collected over each round, then processed, organized, enriched with context, and turned into messages. That mattered because real-time without structure becomes noise, and structure without speed becomes lag.
Fixing latency does not fix everything
After that change, the system was running roughly 30 to 40 seconds ahead of the live broadcast. That alone made the experience noticeably better, but it also exposed the problems that make systems like this hard.
Scale, for example, is not just “send more messages.” Once you are talking to thousands of users through an API with hard limits, everything turns into queue management, throughput control, worker distribution, and making sure the whole pipeline does not back up.
Concurrency becomes a problem quickly too. Multiple simultaneous matches mean multiple active contexts, and if one event leaks from one match into another, that is a serious failure. It may be rare, but it destroys trust fast.
The most annoying part was consistency
Interestingly, the hardest part was not latency. It was consistency. The messages were generated by AI, which has a dangerous trait in systems like this: it is very good at sounding plausible even when it is wrong.
That is a problem because plausible is not enough. If the model invents a detail, mixes up the context, or smooths the message into something that does not match the actual state of the match, the experience breaks.
So we iterated heavily on the prompts until the system could:
- avoid inventing events
- keep the tone consistent
- stay anchored to the exact match context
In the end, the goal was simple: make it sound natural without giving up predictability.
When it starts working
Once latency, consistency, and reliability start lining up, the product becomes something else. Live Status stops feeling like a nice extra and starts feeling like a real way to follow the match.
That is when it gets interesting, because people stop thinking “this is cool” and start actually using it. In an engagement product, that difference is huge.
In the end
Real-time systems are easy to get wrong because they almost never fail because of one huge mistake. Usually it is a stack of small compromises:
- a delay that seemed acceptable
- an inconsistency that seemed rare
- a “good enough” decision that nobody came back to later
In a lot of systems, that slides by. In real-time systems, it does not.
Because in the end, real-time is not just about technology. It is also about perception, and perception is a lot less forgiving than people like to think.