Caching for the win
This summer, I covered how I dealt with a surge of traffic caused by posting on the Fediverse. While it solved that specific issue, it turned out I wasn't quite done.
The list of online players was now cached; that is, read separately then stored locally instead of being read each time. A simple, elegant solution that led the display to be delayed by a minute at most. I had designed something specific for this, and all was good... for a while.
Some of the monthly challenges also involve reading data from the servers. For example, this month's Race Away challenge shows the top position of all our runners. This is again read directly from the game servers and is susceptible to cause the same overload issue as the global list of players.
This time, I chose to take a different approach. I've written a generic function that accepts any data source to save it locally. This reusable element is easy to integrate anywhere, allowing me to cover anything that could use it. I've since updated the list of online players to rely on this, lowering the load on the web server.
A positive side-effect of this new method is that the information is cached then displayed, no matter what. If the remote server becomes unavailable for any reason, it will keep displaying the older information until the problem is fixed instead of offering a blank box. This is also useful when I'm working on something offline, like developing software on a train with no Internet connection: as long as I've read the information once, it will keep on working just fine, letting me run tests easily!
– Doctacosa