## Background
(NOTE) These use cases and requirements are met and implemented since 2011. They are described here for context when we remove/replace this implementation.
ResourceLoader has a "WikModuleTitleInfo" subsystem to track the existence and current revision ID of pages of which the content is bundled inside one or more modules. These are used by user-generated resourced that are created and edited on-wiki. Examples include Gadgets, site scripts, user scripts, and the GlobalCssJs extension.
Use cases:
* In order to support bundling pages like `MediaWiki:Common.css`, `User:Example/vector.js`, and `MediaWiki:Gadget-example.js` in a ResourceLoader module, we need a version hash so that changes actually propagate to browers. This version hash should change based on the composition (page title and order), and content (i.e. last edit's revision ID or last purge, such page_latest or page_touched). The version hash is computed on the `load.php?module=startup` request, which is strongly cached, including for logged-in users, and has a low cardinality, so this has a relatively low backend request rate.
* In order to avoid making `<link>` stylesheet requests in the browser for modules that aren't enabled on the wiki, we need to know whether these pages actually exist (Module::isKnownEmpty). This happens on every page view. Page views have a long tail with high cardinality, thus a high backend request rate, including for logged-in users.
Requirements:
* **Constant time**. There can be any number of such pages on a given wiki. To ensure our backend webserver latency doesn't grow uncontrollably, and to ensure database load stays relatively constant, we need to **batch** these and retrieve them in a single query whenever possible.
* **Caching**. Since we need this information on pageviews, we need to actually perform zero queries in most cases, which is only possible if we cache it in Memcached. This in turn means we need cache invalidation, i.e. after every edit and/or a cache key that naturally caches. See also [MediaWIki Engineering practices](https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Backend_performance_practices), T302623, T347123, and T302538.
Today, we meet the above through three local functions in the MediaWiki\ResourceLoader\WikiModule class: `fetchTitleInfo`, `invalidateModuleCache`, and `preloadTitleInfo`.
## Problem
The implementation has been stable with largely no defect or need to change since 2015. Recently, in adopting Domain Events within MediaWiki core, we found that ResourceLoader consumes one hook that would need to adopt Domain Events. This is fine, but it made me take a new look at this subsystem.
It seems to me that we might not need this subsystem anymore, because MediaWiki core nowadays provides the `LinkCache` service which keeps track of the same information already, in a way that is much more dependency-free. It works quite differently than our implemetnation, so it's not obvious that it can definitely fit our needs, but it seems worth exploring. If succesful, it would allow us to remove this dependency and with it a significant number of dependencies and coupling to other MediaWIki core components.
See also:
* {T32956}