I am a Sr. Software Developer at Oracle Cloud. The opinions expressed here are my own and not necessarily those of my employer.

Rails session storage

May 27, 2017

When we build applications on a singleton server things are very simple. But then we need to start scaling out (usually better approach than scaling up) and we need to worry about session state management. Here is a great article by Justin Weiss and video of his talk on Rails sessions.

Sticky sessions

The simplest thing on AWS Elastic Load Balancer is to enable sticky sessions. ELB will create a cookie and the next time the request comes back it will be sent to the same EC2 instance as before.

The downside is that if we need to take server out of the load balancer to do maintenance / deploy code there could still be users on it. To help with that we need to use dedicated state server or DB to store session info.

Sessions table will have ID (primary key), session_id (ea2c0d7d8b5799c0f48966c9312f95e8), data, created_at and updated_at. Since MySQL / Postgres do not have TTL process we will need to create a background job to clean out these records.

Which approach should we use depends on our needs. If we are already using Redis for other tasks such as caching or background jobs then it may make sense to store our session data. On the other hand if we do not yet have Redis and our primary DB is not under strain then it’s probably simpler to store sessions there.