Caching, Configuration & Feature Flags
Caffeine, Redis, JCache, TTL, Invalidierung, Externalized Config, Secrets und Toggles.
Version 3BetriebCodeDiagramm
In dieser Datei
Caching ist fachliche Entscheidung
Cache verbessert Latenz und reduziert Last, aber erzeugt Stale Data. Deshalb müssen Aktualität, TTL, Invalidierung und Berechtigungen fachlich geklärt werden.
Konfiguration vom Build trennen
Ein Artefakt soll in mehreren Umgebungen laufen. URLs, Limits, Feature Flags und Secrets gehören in Runtime-Konfiguration, nicht in den Build.
Feature Flags mit Governance
Flags brauchen Owner, Ziel, Ablaufdatum und Entfernung. Sonst entsteht ein verstecktes zweites Architekturmodell im Code.
Entscheidungen
| Entscheidung | Gute Praxis | Prüffrage |
|---|---|---|
| Fachliche Grenze | Zuerst Use Case, Invariante und Verantwortlichkeit klären. | Welche Geschäftsentscheidung wird geschützt? |
| Technische Grenze | Framework-/Library-Code hinter Port, Adapter oder Konfiguration kapseln. | Kann die Domain ohne Framework getestet werden? |
| Betrieb | Timeouts, Logs, Metriken, Traces, Security und Rollback definieren. | Wie erkennt der Betrieb Fehler rechtzeitig? |
Ausführliche Beispiele
Cache Key mit Mandant
public record PriceCacheKey(String tenantId, String sku, String currency) {}
@Cacheable(cacheNames = "prices", key = "#tenantId + ':' + #sku + ':' + #currency")
public Money price(String tenantId, String sku, String currency) {
return priceClient.load(tenantId, sku, currency);
}
Feature Flag kapseln
public boolean shouldUseNewRiskCheck(Customer customer) {
return flags.enabled("new-risk-check")
&& customer.region().equals(Region.EU)
&& customer.createdAt().isAfter(Instant.parse("2025-01-01T00:00:00Z"));
}
Typische Stolperfallen
| Stolperfalle | Warum gefährlich |
|---|---|
| Mandant fehlt im Cache-Key | Daten können zwischen Kunden vermischt werden. |
| Secret im Git | Sicherheitsvorfall und Rotationsproblem. |
| Dauerhafte Feature Flags | Code wird unübersichtlich und schwer testbar. |