Redis / Session / Cache Setup

Caching- and Session-Grundlagen for Performance and stability.

Moodle AFANDI standard Handover-ready documentation reviewed on a regular cycle

Quick overview

This page describes the working standard for Redis / Session / Cache Setup – with a focus on concrete decisions rather than general guidance.

The main focus here is which caches in redis liegen and session-strategie and persistenz so that teams apply the same standard.

The standard only becomes traceable through linked evidence such as redis-konfiguration and through documented edge cases/exceptions.

Practical focusTopic-specificVerifiable

When this page helps

Typical situations in which this page adds value as a working document, and where another document is more appropriate.

Typical use cases

  • when for Redis / Session / Cache Setup technical standards about session-/cache-einsatzbereiche must be documented in a binding way
  • when team handovers or temporary cover the same process for which caches in redis liegen should be able to execute safely
  • when incidents or Changes show that evidence such as redis-konfiguration are still missing
  • when configuration or operational deviations (e.g. cache and session be vermischt without zweck) occur repeatedly

Less suitable when

  • when Redis / Session / Cache Setup only about a one-off individual case without need for standardization applies
  • when a detailed project ticket or a technical step-by-step guide is the better fit

Recommended process

A pragmatic sequence that works in practice, from scope to review.

  1. capture the current state and scope for Redis / Session / Cache Setup capture, including session-/cache-einsatzbereiche and critical dependencies.
  2. define the target state and standards; key decisions include which caches in redis liegen.
  3. test changes in a controlled way (Staging, Testsystem or Checklist) and Ergebnis document.
  4. implement in production, run follow-up checks, and redis-konfiguration + monitoring-dashboard link.
  5. Monitoring/Reviews auswerten and recurring Befunde such as „Cache and Session be vermischt without Zweck“ in the standard einarbeiten.

Decision rules

Note: Please do not repeat general documentation rules here. This page focuses on the concrete rules and exceptions for Redis / Session / Cache Setup. Central guideline.

Redis / Session / Cache Setup is well documented, when rules, Edge cases and Evidence so clearly are, dass teams so that without additional coordination work can.

standard case

For Redis / Session / Cache Setup first define the scope clearly: Session-/Cache-Einsatzbereiche.

approval & roles

decisions about which caches in redis liegen and session-strategie and persistenz not implizit lassen, sondern roles and approvals explicitly benennen.

Edge cases

Allow exceptions only if they do not dilute the standard; especially relevant here are ttl and speichergrenzen.

Control point

Verifiable is the rule only, when redis-konfiguration and monitoring-dashboard cleanly verlinkt are.

What should be documented

Here only the spezifischen Inhalte about Redis / Session / Cache Setup maintain; general documentation rules remain in the centraln guideline. Central guideline.

The page is good when a substitute can apply or review the standard without first collecting tribal knowledge.

Definitions

terms, scope and boundaries about Redis / Session / Cache Setup specify in concrete terms, including session-/cache-einsatzbereiche.

Standardkonfiguration / Prozess

Den standard so record, dass which caches in redis liegen and monitoring-schwellen for speicher/connections eindeutig entschieden are.

evidence

Name and link evidence directly: Redis-Konfiguration, Monitoring-Dashboard, Tests after Restart.

Review status

Aktive Exceptions, the latest change and the next review belong on the page—especially for topics with ttl and speichergrenzen.

Common pitfalls

This section captures real-world pitfalls from Redis / Session / Cache Setup; general guidance belongs in the central guideline. Central guideline.

  • scope driftet: Cache and Session be vermischt without Zweck.
  • the rule is too abstract: TTL fits not to the Lernbetrieb.
  • evidence is missing: Restart-Verhalten is not checked.
  • the exception gets out of control: only Infrastrukturwerte instead of User-Sicht gemessen.
Tip: It is better to document three concrete observations from real cases than to keep a long generic list.

Moodle reference (official docs 5.1)

Kurze Verweise on the offizielle Moodle documentation for Redis / Session / Cache Setup. So remains this Page AFANDI-spezifisch and vermeidet doppelte Grundlagen.

Documentation focus

  • Session- and Cache-Backends getrennt document (Zweck, TTL, Monitoring, Failover).
  • UI path, role and test case record explicitly (not only the desired target state).
  • Mark deviations from AFANDI standards separatelyely so that updates remain easier to review.
Note: Moodle interfaces, paths, and options can vary depending on the version, theme, and enabled plugins. Therefore always include the version, role, and test context on the page.

Review & maintenance

Check this Page gegen reale processes about Redis / Session / Cache Setup – not only gegen the Wortlaut. Entscheidend is, ob standard, Exceptions and Evidence in the Alltag contribute.

  • Reichen Speichergrenzen for Peak-Zeiten?
  • Funktionieren Sessions after Restart cleanly?
  • Are Schwellwerte appropriate?
  • Passen Ziele about real Lastmustern?

Review focus for „Redis / Session / Cache Setup“: Caching; check especially session-/cache-einsatzbereiche.

Useful metrics

A few metrics are enough – what matters is that they trigger decisions or improvements.

For „Redis / Session / Cache Setup“ Kennzahlen directly an which caches in redis liegen and the most frequent Praxisrisiken koppeln.

Cache-Hit-Rate

Anteil Cache-Treffer for definierte areas

Interval: monthly

Session-Abbrüche

abgebrochene Sessions through Cache/Redis-Probleme

Interval: monthly

Redis-Auslastung

Speicher-/Verbindungsnutzung in the Peak

Interval: monthly

Next steps

Add jetzt the concrete Entscheidung about which caches in redis liegen incl. Verantwortlichen, Datum and Verweis on redis-konfiguration.

On „Redis / Session / Cache Setup“ make especially clear as the next step: which session-/cache-einsatzbereiche apply in the standard case and which exceptions are time-limited.