- The latency is unacceptably high. A typical round trip time is user noticable, because database accesses are slow. If a serverless function cold starts, the latency will be even higher. Google search shows me an interesting blog measurnig the exact latency numbers (https://serialized.net/2021/03/serverless_gaming_limits/), which aligns with my impression.

- The game can still use a server. Many in game actions required atomic updates to shared state, and many clients can request such updates simultaneously (e.g. increments to team scores on a scoreboard). At minimum, the clients need a serverless function to sequentialize simultaneous updates, such that they do not update based on stale state. However, one database access is already slow, let alone multiple, sequentialized ones. One solution is to add an in-memory cache (such as Redis) for shared state and update that instead. However, an in-memory cache is expensive and unnecessarily complex. The lowest tier of ElasticCache on AWS is $10/month. For comparison, the lowest tier of EC2 server is $5/month, which is sufficient for small games like what I am building. Why use an in-memory cache when I can use memory?

Hence, let me introduce the library.