What's wrong with storing the authorization value in memcached?

Question

PHP

During the authorization procedure, I generate a token associated with the client in one way or another (each authorization will set a new token).
So far, when checking authorization, I have to fetch a record from the DB.sessions database by IP and check the token from the cookie and the token from the database. This routine is done every time Auth->isAuth() is called (called on almost every page); Wouldn't it be considered bad form if I make a copy of the record from the database to the memcache and first of all get it from there and check it, and if the search fails, access the database, and at the end put it into the memcash?
If I came up with a too terrible authorization algorithm, correct me!
PS I'm paranoid when working with the database, and I'm trying to reduce the number of requests as much as possible, because I'm worried about speed. Does this paranoia have a right to life?

Answer 1

In any case, this is not some important data. (by type: user information that is not stored in the database, but it is needed.)
Considering that a new token is created each time during authorization, using memcash is not bad.
The data is deleted when the server is restarted, but authorization will take a couple of seconds)
And besides, it will be easier this way (considering that each page is checked).

Answer 2

1) If you want to store tokens in memory, you can take Redis, it is perfectly designed for this.
From the memcache, data will be periodically lost and you will have to fence the garden with walking in sql.
2) It is worth doing all this or not - it depends on your volumes and the service itself, how much the introduction of such an authorization will speed it up. In some spherical case, I would not take a steam bath if rps is less than 200-300