Game Engineers Solved Real-Time Backends 20 Years Ago. The Rest of the Industry Is Catching Up.

Real-time backends now power far more than games. Trading systems, collaborative editors, live dashboards, fintech platforms, crypto infrastructure, and AI-driven tools all face the same challenge: many clients acting at once, but only one version of truth can exist.

TechGrid spoke with Olga Taranova, a C++ engineer with eight years in game development, including server-authoritative gameplay systems on a live-service title at My.Games, and currently a Technical Lead at Thrylox.

The conversation explores what server-authoritative design means, where real-time systems break, and what non-gaming engineers can learn from multiplayer architecture.

1. Most engineers outside gaming have never used the phrase “server-authoritative.” How would you define it for someone building, say, a collaborative editor or a trading backend?

Olga Taranova:

The term comes from multiplayer game architecture. In a server-authoritative system, the actual simulation runs on the server. The server computes game logic, validates actions, and owns the canonical world state. Clients mostly send inputs and render the resulting state back to the player.

The same idea, that the server is the source of truth, exists outside gaming even if the terminology is different. In trading systems, for example, the matching engine is the only authority on whether a trade actually happened.

Clients submit orders, but the exchange decides the final ordering and execution. The same applies to collaborative editors. Google Docs is server-authoritative: clients send edit operations, but the server determines the canonical order and resolves conflicts.

So the core idea is simple: clients can propose actions, but they do not define reality. The server does.

2. Where do most teams first realize they need a server-authoritative model, and is that usually too late?

Olga Taranova:

In game development there are several signals that make it clear you need a server-authoritative approach. The main ones are competitive games where cheating gives a real advantage, sessions with a large number of players, and games with an in-game economy or inventory. If any of these apply, teams usually go server-authoritative from day one.

But even when a team builds a server-authoritative system, individual subsystems can still leave an assumption that the client can be trusted. A classic example is World of Warcraft. The game is server-based overall, but player movement is structured so that the client reports its position to the server, and the server validates it.

That validation has had gaps for years, which is exactly what fly hacks and speed hacks have exploited. Blizzard has been closing them with patches for more than twenty years, and some of these issues still surface on Classic servers.

The WoW story shows a classic pattern. Choosing a server-authoritative approach by itself does not protect you if a particular subsystem still assumes the client is honest. Once that assumption is found, it gets exploited for years, and closing it after the fact is far more expensive than building validation in from the start

3. What is the actual cost of moving an existing real-time system from client-authoritative to server-authoritative once it’s already in production?

Olga Taranova:

Let’s break down what it would actually mean to fully migrate from client-authoritative to server-authoritative. It is not a refactor of one module, it is a change in the model of how the client and server communicate. Every action that the client used to perform locally now has to become a request to the server.

The server has to validate it, apply it, and broadcast it to everyone. And to hide the latency this introduces, you also need to build prediction and reconciliation on the client. Essentially you rewrite the networking protocol, the server simulation, the state, and the testing surface grows by an order of magnitude.

A good public example is Roblox. Originally, the server accepted any change from the client without validation, applied it to the shared world state, and propagated it to other clients.

In 2014 they added the FilteringEnabled option which enabled server authority, but it was off by default so that existing games would not break. In 2018 Roblox started making it mandatory step by step, and in 2021 they removed the ability to turn it off altogether.

The whole transition took about seven years, and many older Roblox games along the way were either rewritten by their developers or simply stopped working.

That is why the authority model needs to be thought through from the very beginning. If it is not, or if it is done poorly, fixing it later will cost years of engineering work, and sometimes it ends up being easier to rewrite everything from scratch.

4. Multiplayer games have had to handle adversarial clients for 20 years. Most non-gaming real-time systems still assume clients are honest. Is that assumption about to break?

Olga Taranova:

I would phrase it a bit differently. It is not that non-gaming systems naïvely trusted clients. Many real-time systems simply evolved in environments where exploiting the system did not create an obvious immediate advantage.

Multiplayer games were different from the beginning because competition creates immediate incentive to exploit the system. If manipulating latency, movement, inventory state, or timing gives players an advantage, they will optimize for it very quickly. Game developers learned early that every client-controlled state transition becomes a potential exploit surface.

As technology evolves, the forms of exploitation evolve with it. We have seen automation everywhere from ticketing and marketplace bots to much more sophisticated systems like MEV bots in crypto. And with the spread of AI tools, building autonomous bots and other automated systems that probe for exploitable edge cases will likely become far more widespread.

5. Walk us through replication. Why is it harder than just “send the state to everyone”?

Olga Taranova:

Replication is harder than just “send the state to everyone” because real-time games operate under bandwidth and latency constraints. On the client side, the game renders a new frame roughly every 16ms to hold 60fps. The server has to deliver state updates fast enough that the client doesn’t run out of fresh data to show.

The server cannot send the full world state to every client every tick, so replication becomes a filtering problem: what is relevant to this player, how often should it update, and what has priority.

Then the client has to hide network delay. Remote objects are usually shown slightly in the past and interpolated between received snapshots to keep their motion smooth. The local player, on the other hand, is predicted immediately and later reconciled with the authoritative server state if the prediction was wrong.

So the hard part is not copying state, it is deciding what to send, when to send it, and how to keep the world feeling responsive within these time budgets.

6. What does performance optimization look like when the server is the bottleneck and you can’t just add more servers?

Olga Taranova:

When it comes to improving server performance, there are two classic approaches. Horizontal scaling means adding more servers and distributing the load between them. Vertical scaling means making one server itself more powerful.

Horizontal scaling is useful when you need to serve more users in parallel. For example, you can add more match servers so that more independent game sessions can run at the same time.

But this approach has limits when the game design itself doesn’t allow players to be split across servers. For example, in a match with 100 players who all share one simulation, you cannot just allocate a new server, they all have to be in the same shared state.

In that case you have two options. One is vertical scaling: better hardware, faster CPU, more memory. The other is to look at the game code itself and find what can be made cheaper.

The first step here is profiling. You need to understand where the time actually goes: is the bottleneck CPU, network, memory, physics, AI, replication, or serialization. Different bottlenecks need different solutions. The most common cases look something like this. If CPU is saturated by the cost of simulating all the objects in the world, you usually use culling: skip processing entities that no player can see or interact with, reduce how much each object is simulated when no player is looking at it.

If the bottleneck is network bandwidth, you send only what has changed since the last update instead of full state, reduce update frequency for less critical objects, group small updates into one packet, and compress data so each field takes fewer bytes. But these are just typical patterns, the actual fix depends on what the profiler shows.

7. Where do real-time backends fail in production in ways that are hard to predict from testing?

Olga Taranova:

Real-time backends usually fail in production through things that are hard to reproduce in testing. The two most common patterns I see are scale-dependent failures and unexpected user behavior.

Some systems work perfectly under staging or synthetic load, but break once real concurrency, latency, retries, and traffic patterns appear in production.

The second category is users interacting with the system in ways the team never modeled explicitly: unusual workflows, coordination, automation, or usage patterns that change the shape of the problem itself.

8. A lot of fintech and crypto infrastructure is now described as “real-time.” How would a game engineer evaluate the claim that a given system is actually real-time?

Olga Taranova:

A system is real-time when it has to satisfy two criteria at once: the logical correctness of the result, and the time within which that result is produced.

In game development both criteria matter continuously during gameplay. If a frame is computed correctly but arrives too late, its value is already lost from the player’s perspective: the result is perceived as stutter or a missed interaction. On the other hand, if the server sends updates quickly but the state itself is incorrect, the outcome is still broken gameplay.

In other industries the term “real-time” is often used more loosely to describe streaming updates with low latency. So when something is described as “real-time”, a game engineer would usually ask two questions: is the state still correct under concurrency and load, and are timing guarantees still maintained under worst-case conditions?

9. AI agents are starting to act as clients in real-time systems. From a server-authoritative standpoint, what changes?

Olga Taranova:

From a server-authoritative standpoint, the architecture itself does not change, the server is still the source of truth and validates every action.

What evolves are the mechanisms that analyze client behavior on top of it, like rate limiting and behavioral anomaly detection, which in gamedev have been part of anti-cheat systems for years.

For example, thresholds for actions per second that used to flag obvious bots have to be rethought, because an AI agent can easily operate at rates that look like cheating by human standards.

10. If you were starting a non-gaming real-time system from scratch in 2026, what’s the one thing you would do differently from how most teams approach it?

Olga Taranova:

Real-time systems have a few core challenges: the state changes constantly, multiple clients interact with it at the same time, and users expect near-instant response. In practice, most problems come from things that were not thought through in the architecture upfront.

So the one thing I would do differently is invest more in the architecture early, especially around the points where users compete over shared state or resources, how those conflicts will be resolved, and what guarantees the system actually needs to provide.