Hey mate!

Good question! I won't talk specifically about FB (I have no experience) but I can talk in generality; indeed, these games would need to persist their data, and I'd assume they are using a relational database to do so. There would be many methods to persist data (raw data on disks, relational DBS, non-relational DBS, etc) each one having their own benefits. From the start, it may seem simple; connect a MySQL server, write a forward facing API (ruby, PHP, etc) or an API followed by a multi-tiered architecture, and you're done. No need for heavy weight engines like App Engine.

But - here's the crux - scale can become an issue. Assuming 90% reads, 10% writes on a standard database, you may need to alleviate reading (read replicas, caching) and then writing (sharding, queues), etc. So it becomes quite technical, quite quickly. Of course, this assumes you're doing all this stuff yourself.

Non-realtime games can exploit message queues (RabbitMQ, Amazon's SQS) and coupled with on-demand computing, this can be quite effective on the cloud.

Hope this helps!

Adrian

(Cloud software developer, lead backend dev at https://www.yellloh.com/)