This question is about best practices in architecture.
Our Current Architecture
I have a PHP class that accesses MySQL for user info. Let's call it
User is accessed many times, so we have implemented layers of caching to reduce load.
The first layer is what we call the "per request" cache. After the data has been retrieved from MySQL, we store the data in a private property of
User. Any subsequent requests for the data returns the property instead of re-requesting the data from MySQL.
Since the web request lives and dies on a per-request basis, this cache only prevents the application from accessing MySQL more than once in a single request.
Our second layer is Memcached. When the private property is empty, we first check Memcached for the data. If Memcached is empty we query MySQL for the data, update Memcached, and update the private property of
Our application is a game, and sometimes it is imperative that some data be as up-to-date as possible. In the span of about five minutes, a read request for the user data may happen 10 or 11 times; then an update may occur. Subsequent read requests need to be up to date or game mechanics fail.
So, what we've done is implement a piece of code that is executed when a database update happens. This code sets the key in Memcached with the updated data, so all subsequent requests to Memcached are up to date.
Is this optimal? Are there any performance concerns or other "gotchas" we should be aware of when trying to maintain a sort of "living cache" like this?