(i) Runs as separate process, one thread. In the future, there might be a communication channel between Resolver processes and this one.
(ii) Accesses resolver's cache and if it's close to full, deletes expired records. Race conditions of concurrent access are solved by LMDB.
The biggest problem is allowing server-stale feature of resolver, because this feature is not yet well described.
It is not clear in what circumstances an expired record may be deleted from the cache.
"Delete most expired records first" seems to be a good idea, but IMHO is not.
There might help a special flag/counter for stale records that have been already used as stale records, but i wouldn't change data structures without clear design/requirements.
The only thing clear is deleting records that are expired for > 1 week.
A program that deletes all expired records from given cache (one-time).
Only deletes expired records if occupied > 80%.
A daemon which does this periodically.
Configuration tools, reading configuration from file, configurable parameters.
Whitelists for (templated) records which will be not deleted, or deleted only in case cache almost full.
Important note: the resolver shall avoid long-living transactions to the cache LMDB, otherwise deleting makes no effect on space usage (the records are still there until all read-only transactions are ended) !!