HACKER Q&A
📣 sosodev

Ideas for scaling and monetizing a web game with chaotic usage?


Several months ago I developed a web game for a Twitch streamers to play with their viewers. It was developed for a specific livestream that averages several thousand concurrent viewers. I knew when the stream was going to start so I was able to preemptively scale up the backend.

Since then the game averages a few hundred hits a day with unpredictable massive spikes in traffic when other big streamers play it.

Currently it takes several minutes for the backend to automatically scale up from the typically tiny load. The scaling up process also makes the website really slow/glitchy and it kind of ruins the user experience.

I think this is an ideal use case for serverless tech but the game uses a database and websockets which seems like it will make the serverless path quite complex and costly.

Which brings me to my next problem... How should I monetize this thing? Currently I solicit donations but those only cover a fraction of the cost. I think it would be best to ask the streamers to pay to play but I don't want to discourage them from playing while the game is still growing. Maybe I should just eat the cost while things are scaling up?

  👤 an_ko Accepted Answer ✓
Just throwing ideas around:

I feel like streamers paying for usage beyond a certain threshold of simultaneous players might solve both problems.

That way they could play it for free capping out at fewer players (number chosen to still perform ok while your autoscaler catches up) and if it's fun, pay to include all their viewers next time. Then you could afford to increase your reserve capacity accordingly.

Depends on the game, but if the usage pattern seems too "one-shot" for a subscription to be appealing, could sell in the form of advance bookings, so you could prepare for large crowds ahead of time.