Document our various caching and persistence levels
- Dominant language
- Go
- Stars
- 4.8k
- Forks
- 542
- Avg merge
- 7d 21h
- Merged PRs (30d)
- 2
Description
"7 layer burrito of the athens cache"
* go cli on a worker caches to the filesystem in the GOPATH/pkg/mod
* in-memory storage
* filesystem storage
* redis storage
* mongo storage
* the go cli on the client end
What is the lifecycle for each layer? If I restart the proxy, what do I expect to see when the cache is full vs. empty? We will see different behavior depending on how it's run (i.e. in a container with ephemeral storage, or on a host with just a single worker, where the go cli disk cache comes into play).
This will help operators (and the curious) know when the caches come into play and what they should expect on cache misses, or where to monitor for storage concerns.
Contributor guide
Research direction
No files, tests, or entry points are named. Use the six cache layers listed in the issue as the outline, then document each lifecycle, restart behavior, cache-miss behavior, and storage implications for ephemeral containers versus host-based workers; done when operators can predict what happens and where storage concerns arise.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, mongodb, redis
- Domain
- backend, databases, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100