Should the API server store user session data? Or the application server?

I've been wondering what are the advantages/disadvantages of storing session data on the API server. It seems a bit more intuitive to store session data on the API server, but I could see benefits of keeping the API stateless and using access tokens to access data.

What are your thoughts?

Thanks! Matt

I would say, it is good to store session in a server other than application server and API server.

Because of speed, memcached and Redis is used as session storages. They are fast because they are memory-based.

For scaling-out, I recommend you to separate session storage from API and Application server.

Even if you had problem in application and API server for certain period of time, sessions would not be lost in that case.

From what I've read so far, neither.

There's another similar question that asks whether, in a true REST-style setup, the Application Server or the Database Server should hold the sessions. Several people responded that, while it's sometimes faster or more convenient to keep on the application server (or in your case the API server), it's preferable to store sessions in a database or Memcache.

If you keep them on the API Server, you run the risk of losing the sessions if the server crashes.

Also, (I paraphrase from AJ) keeping your sessions on the API server will only work if:

  • Your clients always connect to the same server (aka "session affinity")
  • Your server nodes all use a common mount point to spool sessions

I'm not sure the second one applies as much in this situation, but the database and/or Memcache (Thanks InspiredJW) idea does sound your best bet!

Thanks much