Why use memcached or redis instead of cookies when saving sessions?

For various reasons, you may want to have session data on the server side.

HTTP (1.1) does not have a protocol state, so it is completed in one exchange of the server responding to requests from the client.Cookies, on the other hand, place data when the server responds, and the client "simplely" sends it back in subsequent requests.In other words,

• All data stored in cookies is server-derived or client-sent data
• Not intended to manipulate the data on the client side

Therefore, it is sufficient to "keep the data on the server side and inform the client only the ID that identifies it."It's useless to send data that you don't need to send over the network, and there's a risk of tampering and eavesdropping here and there, so I'm sorry.The only way to communicate is to communicate with this session ID.

Rails, on the other hand, is criticized for storing session data in cookies by default, but Rails' idea is that storing important data in session data is strange in the first place, so it's a nonsense criticism.

Saving data in cookies (not session IDs) is also an advantage, eliminating the need to share session data between application servers when they are distributed.

With the session ID method, all servers must share session data, and each time a request is made,

It's a load and management challenge, like having to manage expiration dates and purging them appropriately.

(Sometimes there is a system that has multiple servers but doesn't share session data.)

However, since it makes more sense to exchange only session IDs as previously mentioned, the idea is to use lightweight and fast data storage that uses session IDs as a key to process data for session data.This is KVS itself, so memcahced and redis will be used for it.The life cycle is different from the data stored in the RDB, and there is no need for backup, so it's better to use a different storage.

·In the case of cookies, is there any way to have data on the server side?
Do you understand how cookies store data in the first place?Cookies are
[1] Send a response containing the cookie information that the server wants to store in the client (browser).
[2] A browser receiving the cookie information stores all other cookies received from the same server, and stores all of those cookies in all requests to that server.
It is a method of storing data that is established in the form of .
　Nothing like having data on the server side is called a cookie.

·Other reasons why I prefer to use redis
　In particular, I do not feel that redis is preferred and used, so I would like you to tell me why you felt that redis was preferred.However, as a general trend, it is assumed that all requests must be read, so I think a framework that is as light and easy to access as possible is preferred.

• As explained in how cookies work, all cookies sent from the server are stored on the browser side, so it is easy for a small user to rewrite them.(Most browsers now come standard with developer capabilities, so you don't need any special tools.)
• Also, because of how cookies work, data stored in your browser is added to your request every time you submit a request, which is not desirable in terms of increasing traffic volume.

These are the two main disadvantages of using cookies as session information.I believe that Rails's assumption of cookies as a standard session destination is the biggest design error for Rails, but there are some applications where the above two points are not necessarily considered a drawback.