If what you are after is the elimination of global state in your application then the
static keyword definitely sucks to have in your code (you say you don't like it, so I'm going to assume you know the disadvantages the
static keyword brings to application development).
Considering the cache issue, whether it is in-process or out-processed to a system such as Redis, it would not really matter what exactly you were using, be it memory, file or Redis, as long as the cache layer was
static, everything would really stay the same (it would be global).
Needing a good caching layer is definitely not a trivial problem. During my becoming of hopefully a better programmer I have gone through about 5 versions of cache layer interfaces (which either I or a team I was on coded), before finally arriving to a solution which I liked.
But even then, having well documented caching layer (a
static one aside, because that's a thing I try to avoid in my applications) is not a solution to a problem but merely a mean how to achieve it.
The problem is something entirely different, that is my application is slow, I want to cache certain data and I want to do it efficiently based on the design of my application.
The two problems which occur most often when you are considering creating a caching layer are the following:
- Do I want to share cache among processes?
- Do I worry about having thousands of processes, each having its own cache poluting the memory pool?
There are many different types of applications: standalone apps the client installs, web applications, web services (REST, SOAP), web presentations,...
For all these a caching layer may be considered as a possibility to make the application faster, but there is a problem, the applications are completely different and for such different approaches must be taken when trying to design cache.
Cache for web services
Web services, REST, SOAP, usually have one task. Abstract direct connection to a database so clients can consume the database data without you being forced to expose your data source. On top of that middle layers may be added (such as balancing or cache in question) to improve the performance (usually calculated from response time).
Whether you want an in-process cache or an outsourced one (file/Redis, does not matter), depends on the design of your application.
Consider a PHP web service. PHP works in a way that for each request a new instance of an application is made. This means, if you cached data in-process, the cached data would be only available inside the single request, which could speed up your application a little, but if another endpoint consumed the same data as the endpoint which was first hit, the second endpoint would need to load the data all over again, because it couldn't access the cached data from endpoint one process.
Naturally, you'd want to share the cached state, therefore you'd have only one option. Either make your own caching system, most likely using files, or use a system like Redis, so different processes can access the same data and don't need to hit the database.
On the other hand, if you had a web service, which would have only one instance and memory was shared between endpoints, perhaps in-process cache would actually be a better alternative, considering multiple endpoints would still be able to access it.
Your colleague is afraid of performance hit because you need to go to the Redis server rather than directly accessing memory. Believe me, that is really the slightest of problems. The performance drop is so little that it is still better sharing state of database using this way than having to query the database directly.
You can define how you want to store the data in Redis, choose the best data type for your problem. It's quite obvious, traversing a binary search tree for a value combination based on some hash will be faster than having to query database and compose the data inside.
Yes, databases have caches themselves, but even then it's either:
- query db -> db calls its cache -> db gets data from cache -> db returns data
- query cache -> get data
Fewer steps usually means the operation is going to be faster and in this case it is.
You should cache into outsourced cache things which you know will be shared among requests (data from database is usually shared). For how long and how much data you want to actually cache is up to you and your business rules.
You should cache in-process things, which you know are available during one specific request, will need to be available multiple times during the request but do not affect other requests.