[rfrey]

A question so noob I'm almost shy to ask it:

The simplest scenario in the article is a single Redis instance residing on the same machine as the application. What's the benefit to this versus just storing data directly within the application?

[Groxx]

Storing it in a different process at the very least lets you restart/deploy changes to/crash your application without losing that data. Or building your own replication/in-place upgrader/well you're just screwed if it crashes.

[halotrope]

Sometimes your application has multiple instances even on the same machine. Scripting languages like Node or Python don‘t share memory. With Redis they can share state in a high-performance manner.

[intelVISA]

Database-as-IPC makes me feel uneasy... even if it's kinda OK with Redis.

[piaste]

Your application and runtime are probably tuned to act as servers, with short-lived requests and little or no persistent stage, and they may not play well with keeping a bunch of persistent data around forever.

I personally first reached for Redis when I needed to asynchronously process a bunch of JSON uploaded by clients via POST. I initially just stuck them in a ConcurrentQueue in memory, but no matter how much I fiddled with HostedServices and BackgroundWorkers and whatever the MS documentation recommended, the ASP.NET Core app would occasionally 'lose' that queue before it could be consumed (or the consuming loop would get stuck, with the same result).

You are also probably running your app on a pretty high-level language, with bytecode and reflection and all that nice stuff - if not even an interpreted language - while Redis is raw C code and will outperform your homebrew double-linked list or hash set.

[louissm_it]

Storing the data directly inside the application still means you need to store it somewhere, likely a SQL database (such as PostgreSQL). These databases are insanely well engineered and very very fast, but compared to a key value store such as Redis and Memchached they are comparatively slow and resource hungry (because they are optimized for different things).

So if you can fetch some cached data from a Redis key, even if on the same machine, it will cost you significantly less than querying a relational database.

[halukakin]

Not all applications can store data out of the box. For instance some ways of PHP have embedded caches, some others don't have cache by default and you would need to install cache software (for instance apcu). Also, redis has many different types of data. For instance coding something similar to its "hash" data type is not trivial.

[radicalriddler]

Redis persists on disk (well, it's optional), if you restart your server I'd assume that it'd be able to restore the disk data into memory, versus your applications memory, which would just be lost.

I'm not a Redis user, but that's based on what I've read

[ok123456]

Short lived processes/workers.