The point is that you don't need multiple processes and Redis most of the time. Your site can easily be served from one box and one process.

That depends on what you're creating and how. For better or worse[1], not everything follows the one-enormous-process Java way of doing things.

Btw, Redis is extremely fast to set up, but as I sai, if all you need is a HashMap..

[1] - Almost always for the better if you ask me. That Java "enterprisy" way of development is the worst thing I have ever experienced in computing ;)

Even multiple threads - any sort of concurrent access/modification on the same dataset becomes problematic if you just use a HashMap.

Sites that have any kind of download/upload component, even though does not have too much traffic, will need to serve multiple requests using threads/processes.

That is where we normally use relational database. However Redis presents a way to be faster than conventional databases by storing everything in memory. This is as close to a concurrency-safe HashMap that you can get with the least amount of effort.

But Java comes with several currency-safe hash-maps and trees and such - where have you been?

If you think that blocking TCP calls to a redis server that serialises everything is going to be faster than a `new HashSplayTree<String>()` you're absolutely bonkers.

"This is as close to a concurrency-safe HashMap that you can get with the least amount of effort."

No, it's more effort than using a concurrency-safe HashMap in a JVM process.