Adding to @rmoran86, There are few more things you need to take care. Something like when you get a request to modify, like

1. When you update user details, first update user details in #mysql and if the update is success then update in #redis.
2. If you get a request to delete user details, you delete user details from #mysql and then perform the same on #redis.

There are multiple ways you can perform, this is one way I suggest.

Think of your application logic as the following 3 layers :

1. Application Code
2. Redis Cache
3. MySQL Data Store

MySQL acts as a permanent persistent data store for your app while Redis acts as a proxy between your Application Code and MySQL store. When you are calling getUserdetails() , you should first check in the Redis to see if there is any data already cached. You can check this by using EXISTS command in Redis. If a particular key exists, it means the data is cached. So, you should just go ahead and fetch it and send it to the user. Otherwise you should hit the MySQL DB, fetch data & serve the user and then store it in Redis for future access. You can also set a expiry time while storing a key in Redis in which case the key will be deleted after the specific period.

Let me know if you need more help!

There is no one size fits all answer to this question, but this seems to be going about things the wrong way. "Premature optimization is the root of all evil." How exactly do you know that query caching is the bottleneck of your application, as opposed to not using a queue for processing requests?

Redis is best used as an application caching system and not a database caching system. When you think about it, you'll understand why.

If you want to cache queries, you need to know when they were last updated. Otherwise, you're not implementing anything other than a guessing system. "I guess I should delete this particular query cache every 24 hours." Well, what if your customer logs in immediately the first time, then changes their information in Userdetails? They have to wait 24 hours to see it updated. They'd assume your system or application is broken.

How else could you go about it? Well, you could do something like have a timestamp on Userdetails for something like "Last Modified". You'll see this in most Laravel and Rails apps that each data table has a last modified property.

Perform the query, check the last modified against the value you have for it in Redis, and then either execute the query or use Redis to serve up a cached version. Did you catch the problem there? You're still performing the query. Without running a new query or checking the query cache, you don't know whether or not you're serving stale data. The performance boost is going to be minimal. You can even introduce new bugs into the system like this:

en.wikipedia.org/wiki/Cache_stampede

You can implement a less naive caching system by caching things that are always going to be the same, e.g. cache a query like "SELECT * FROM comments where id = 1", since the id is unique. Still, same problem occurs if the comment is updated, you're serving stale data.

Instead, for parts of your system that require less latency replace MySQL with Redis, MongoDB, or another NoSQL system. This is a lot less headache to implement effectively. You should also look at questions like whether or not you should set up a replication server to perform most of your reads, using a queue effectively like Resque (which is Redis backed), and so forth.

Put most frequent used data in Redis and like said above, when there is a change, do update on Master (MySQL) first and then update same on Redis.

Frequent used data differs from application scope. Good example will be storing emails in redis cause user opens and close email very frequently.