Optimizations in browser games

A long time ago, when the first widely popular browser games started – mostly sci-fi themed games centered around colonizing planets, gathering resources and building fleet to blow up other fleets – things were moving along in a very deliberate pace. Usually there were so called "ticks" at regular intervals at which ongoing processes would be updated. That included calculating resources gathered, moving fleets around and playing out their engagements.

As games became more complicated and more engaging moving to real time processing was a natural step. But while running a couple SQL updates every 15 minutes with a couple thousands users might have worked, that same approach quickly runs into trouble if you multiply the userbase and try to get even close to real time updates, or even if the calculation become more complicated that what can be done in an SQL query.

One solution is to go lazy. As long as something can be calculated reasonably fast, especially if it can be done on the client side, there's no reason to update the database until absolutely neccessary. Example:

A player has 1000 units of Resources #1 and produces 1800 units per hour. If you take those two data points, plus the time the resource count was updated last, you can easily calculate the current amount for display purposes on the client side. Most games utilize this already in order to have running counters on the frontend. So with a little javascript magic, the user in this example will see their resource count increment by 1 every two seconds.

How lazy can you go in this example? The only times it's neccessary to update the database is when one of the two main datapoints changes, i.e. when there are changes to the basecount or the production rate.

As a general rule, you can apply the quatum mechanical observer paradox, wherein something is indeterminate until you look at it. Think Schroedinger's Cat.
From the viewpoint of the database, the current resource count and the results of other ongoing processes can be undetermined until somebody, a user or a process that needs hard data, comes looking for it.