Postgres etc are more complex than Redis, are they not?
Does your argument assume you already have a database, so you might as well use it for your cache mechanism?
Postgres etc are more complex than Redis, are they not?
Does your argument assume you already have a database, so you might as well use it for your cache mechanism?
Modern rdbms databases already have an in-memory cache. For 99% of projects there's no actual difference. The round trip will end up around 12-22 ms in all best possible cases.
If you're getting 12-22ms latency for your cache reads, the network is your bottleneck. If stored locally, you would get many orders of magnitude faster than that.
The network IS your bottleneck. That's exactly what I'm saying.
Don't even start a socket if possible.Now then do a traceroute. Even to my router it costs 0.547 ms but that's only 1 direction. And a cloud space is hosting many servers, many routers, many switches, with lots of moving pieces so you're realistically adding 1.1 ms per subnet hop and in pretty much every data center that's probably 3-5 hops inside the LAN.
Gotcha. Yes, if you have your cache (let alone services) all across different machines, then this is all irrelevant.
The real question, which few ever ask, is whether your app actually needs more than one server. Servers are so insanely large (up to like 400 Cores) and powerful now that you can get meaningful scale on a single box.
If you can colocate the app and cache (and maybe also the db) on the same server, you can get many orders of magnitude better performance, regardless of which cache it is. Redis, memcached etc all can do 100k or more gets per second (dragonflydb etc claim 10x that due to multithreading).
Hell, with RAM being so expensive now and NVME so fast, sqlite is a VERY attractive option for cache. Plenty written about projects adopting it. Rails in particular is a champion of it.