Virtually every page and refresh in this scenario would require a call to your update function.
The above statement is false.
javascript timer that will call update() on completion
You have to be careful & clever there. Done wrong, this could be a potential bad practice / security threat - allowing me to easily skip the timer and call the update() when I please ('Why would I wait 20 mins to have it built / done if I can have it now')
Let's start over.
Some assumptions to make first: we have a browser based rts game - database driven, markup + js on the frontend of course. Let's assume 1000 players for the numbers sake. The game has the usual - displays money + some stats at the top, allows to purchase buildings, army, view & attack other players' kingdoms (takes time until your army reaches enemy). And we try to achieve the 'real-time' gameplay feel.
I'll try to reword the 'build a building' example:
Scenario 1 - The User buys a building:
DB pseudo-structure
1) You have a 'buildings' table in your db
2) Let's not get into the details of what params (table columns) can the buildings have (also skip the obvious columns like ids, etc.). For this 'real-time' example all the columns we should care about are like: building_name, price, status, time_it_takes_to_build, created_at, updated_at
The action
1) User clicks 'Buy Building Blah'
2) You create a new building for this user in the db; you take off the price from the amount of money the user has; you set the status to 'under_construction'; both created_at and updated_at you populate with current server time at this stage. Knowing current server time is a given, it's there for you all the time, no performance probs - it's also a big player in the further part of the story;)
And voila! - you're done, it's pretty much the same thing you would do always - regardless of whether you use Cron or not, so no performance talks here.
Scenario 2 - the infamous page refresh (The User decides to have a look at his buildings, etc.)
1) 'Click'
2) You GET user's building from db - there's a good chance that's gonna be the only db hit (and no updating)
3.1) The building has status of 'under_construction'. Well, right there you already have when the buildings was purchased (created_at), how much time needs to pass for the construction to complete (time_it_takes_to_build) and something you always have, no matter what - current server time. Now it's easy;)
- 3.1.1) If enough time passed since the created_at till now, only then you update: status => 'complete'; updated_at => current server time. On a page the user sees 'This building was built format_time_nicely(updated_at)'.
- 3.1.2) If not enough time passed, you echo 'building will be ready in time_remaining' - on the user's machine (after page is loaded) you can grab the number easily and have a nice js countdown (no talking to server there)
Well, there you go;) Hope you do not see 'updating everywhere' now, but updating ONLY when you actually should be updating. And most important - it's a 'real-time' game, players always see uptaded stuff - there is a feel of 'constant flow', etc.
With 'cron-way' (the way it was put) you would:
1) skip checking times - not really a performance boost there.
2) not have occasional update statement - hmmm.. mild performance boost, especially with all the js / ajax goodness which make 'waiting time' much less obvious and painful for the user
Plus, what seems to be the reason of why I am even talking against Cron here:
1) How do you achieve this 'real-time' effect with Cron, without stupidly low interval (seconds) - big performance issue
2) Imagine this: 1000 players online, 300 refreshes the 'view my buildings' page - the rest stares at the screen doing nothing:
- Without Cron - could be lightweight / slightly heavier requests (depends if any updates necessary or not). But all the happy players would have the correct, up-to-date info constantly
- With Cron - lightweight requests, info displayed to users most likely out of date until next Cron job. Then when it happens - you would have to run a giant loop through all the players, checking / updating every single detail - buildings, money, army, fights, etc. Even if most players had nothing to update, you'd still have to go through every single detail.
Hmmm...
My argument for Cron and updates no more frequently than once per 15 minutes is that it provides a much cleaner approach with some minor overhead savings. There are several other arguments here to support Cron, but its really for the OP to decide.
. 
