My consultancy took over a fairly busy Django application that handles Caching via Redis EXCEPT for Django.session data. The only information available is a commit message like “Reverting session storage via Redis”.
I’ve tested Django sessions stored in Redis and it seems like a nice fix but I am hesitant to push it down the pipeline as I am wondering why the original dev pulled it.
As I understand Django sessioning logic, it’s just a key:value store where value is a pickled Python object with relevant session data.
Short-version:
What is the downsides of using Redis to handle Django.session data?
Redis is the fast and quick way to store your sessions instead of adding them in your SQL DB (try to monitor the time taken to query sessions table), that will be obviously clear if you use some tool like django-toolbar app.
On the other hand, the only thing that might show up as a problem is your sessions data persistence, which has been taken care of in Redis with 2 different methods, you can choose whichever suits your needs, please refer to the documentation for more details, plus the options of making clustering or fail-over Redis servers.
I came across a similar situation where I needed to to store my sessions in a NoSQL DB for speed and other project-related reasons, which happened that I used django-redisession app, I would recommend giving it a try.
Finally, regarding the shopping cards problem you have been talking about, this absolutely has nothing to do with Redis, please check your system configurations and how different software components interact with each other. I would also suggest making your tests in a replica servers instated of doing that on production servers, to make sure that everything is properly working and well configured.
Update
Btw, Stackoverflow uses Redis for session handling, which is a pretty strong example of session management using such NoSQL DB as a backend.