Costs and scaling

Play this lesson

What if 10,000 players show up?

Imagine Garden Defense gets featured, and 10,000 new players arrive in one day. Great news. But every one of them logs in, loads a save, writes progress and opens the leaderboard.

Each of those actions is work for the servers of Firebase, our backend service, and server work is what cloud services charge for. So before launch, we learn how the bill works and how to keep it small. Growing to more players smoothly is called scaling.

How Firebase charges

At the time of writing, the free Spark plan allows about 50,000 reads, 20,000 writes and 20,000 deletes a day, plus 1 GiB of storage. Hit a limit, and that feature stops until the next day. The Blaze plan is pay-as-you-go: the same free allowance, then a few US cents per 100,000 extra reads. Prices change, so check Firebase's pricing page.

Quick check

On the free Spark plan, our game can make as many reads as it likes, as long as we never upgrade.

Show the answer

False

Spark has daily limits. Once a limit is reached, that feature stops working until it resets, which on launch day means players can't load their saves.

Do the maths first

Say each of the 10,000 players opens the leaderboard 5 times a day, and each time the game reads the top 10 score documents.

That's 10,000 x 5 x 10 = 500,000 reads a day, or about 15 million a month, just for one screen. That's ten times the free daily allowance. On Blaze it's a few dollars a month, and it grows with every new player and every new screen.

Doing this sum before launch is how real studios avoid nasty surprises.

True story: Pokémon GO's launch

Before Pokémon GO launched in 2016, its maker Niantic and Google's cloud engineers planned for a target amount of player traffic, with a worst case of about five times that. Then players arrived at 50 times the target: ten times the worst case.

Google added capacity fast, "many tens of thousands" of processor cores (the parts of a chip that do the work), to stay ahead of the growth. When the game launched in Japan two weeks after the US, new sign-ups were three times the US launch.

Even experts guess low. So we do the maths, then plan for much more than our guess.

Source: Google Cloud blog: bringing Pokemon GO to life on Google Cloud (2016), cloud.google.com

Cache the leaderboard

A cache is a saved copy we reuse instead of fetching the same thing again.

Every few minutes, a Cloud Function (our own code running on Google's servers on a timer) builds the top 10 into one document called leaderboards/daily. Now each player reads 1 document, not 10. The phone also keeps its copy for a minute before asking again.

Same board, 10 times fewer reads. Together with saving only at key moments, like the end of a wave, this keeps our bill small.

Count the reads

Kai drafted three leaderboard designs for 10,000 players. Which one causes the most Firestore reads?

  1. Each player reads one cached leaderboard document when they open the board screen
  2. Each player reads the top 10 score documents every second while the game runs
  3. Each player reads their own save once when the game starts
Show the answer

Each player reads the top 10 score documents every second while the game runs

Ten reads every second is 600 reads a minute per player, even when nobody is looking at the board. Times 10,000 players, that's 6 million reads a minute.

Hosting on Cloudflare

Our game files (HTML, JavaScript, images and sounds) never change between players. Files like these are called static. We host them on Cloudflare, which copies them to data centres all over the world, so each player downloads from one close by (Stage 7 shows how it works).

At the time of writing, Cloudflare's free tier for static sites is generous, so 10,000 extra downloads shouldn't cost us anything. The part of our bill that grows with players is mostly Firebase.

Budget alerts and the dashboard

The billing account for Blaze is a payment contract, so it belongs to a parent. Together we agree on a monthly budget, then set budget alerts that email us when costs reach, say, 50%, 90% and 100% of it.

An alert warns, it does not stop spending. So we also check the usage dashboard in the Firebase console, which shows reads, writes and storage day by day. A sudden jump usually means a bug, like a save inside update(), the function that runs 60 times a second.

Quick check

Our budget alert emails us that we have used 90% of this month's budget. What has the alert done?

  1. Stopped all spending so the bill can't grow
  2. Warned us, so we can check the dashboard and fix the cause
  3. Deleted old saves to make room
Show the answer

Warned us, so we can check the dashboard and fix the cause

Budget alerts only send a warning. It's up to the team to open the usage dashboard, find what is causing the reads or writes, and fix it.

Cloud connected

Look how far we've come. Our games have a backend, requests and JSON, instant logins, cloud saves that sync, fair leaderboards, real-time listening, cheater checks, code on the server, data handled with care, and a plan for the bill when players pour in.

Saves no longer vanish. Next stage, we make the studio official: a real company, with its legal homework done.

Bolt says: One more bill before the boss quiz: the AI itself. Next lesson, what AI costs.

Fact-checked 11 October 2026