Architecting Moodle's Universal Cache (MUC) for Scalability
Learn how to architect Moodle's Universal Cache (MUC) to prevent database bottlenecks, avoid data inconsistency in multi-node clusters, and secure your cache boundaries.
ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Learn how to architect Moodle's Universal Cache (MUC) to prevent database bottlenecks, avoid data inconsistency in multi-node clusters, and secure your cache boundaries.
On multi-node Moodle, every web server rebuilds the same caches on local disk. Pointing MUC's application store at Redis shares that work — here's the config, the mapping strategy, and the eviction-policy traps.
Goal Determine how Moodle’s Universal Cache (MUC) behaves when a configured Redis store becomes unavailable on a low‑traffic, single‑server deployment. Constraints and uncertainty The site runs Moodle 4.x with MUC configured to use Redis as the primary cache backend and the default file store as a secondary backend. The server has limited RAM and CPU, so any