Create cache interface to store frequently accessed I/O bound data

[kyujin-cho]

After #1911 is resolved, we need to think about implementing cache interface to store frequently accessed, I/O bound datas. API responses from Harbor API will fall into this case. Interface must be designed in a way to utilize heterogeneous cache backends, but for now let's just think of using only one cache backend, redis.

[achimnol]

Just an idea: Could we consider some build-artifact caching solutions (like what Pantsbuild uses...)?

[jopemachine]

I’m leaving a question as I don't fully understand the issue.

Problem Situation

When caching large responses from the Harbor API in Redis, using outdated responses becomes an issue if the registry is updated after caching. For instance, if you cache the results of an image rescan and then use this cache for the next image rescan, any new images uploaded to the registry in the meantime won’t be scanned.

Questions

Cache Invalidation Timing

To avoid using outdated responses, cache invalidation is necessary, but it’s unclear when this invalidation should occur. For example, if you clear the cache with every image rescan, you essentially won’t be using the cache for rescanning. This implies that the cache should serve other purposes. What tasks, then, actually use this cache?

Criteria for Caching Responses

Which types of responses should be cached? Should every response from the Harbor API be cached if it exceeds a certain size, and should this size threshold be hardcoded or configurable? Alternatively, should caching be limited only to responses from specific tasks, such as image rescanning?

[jopemachine]

Due to the unclearness of this issue, I will put this issue on hold and work on #1913 first.