meldestelle/infrastructure/cache/README-INFRA-CACHE.md

Infrastructure/Cache Module

Überblick

Das Cache-Modul stellt eine zentrale und wiederverwendbare Caching-Infrastruktur für alle Microservices des Meldestelle-Systems bereit. Caching ist eine entscheidende Technik zur Verbesserung der Anwendungsleistung, zur Reduzierung der Latenz und zur Entlastung von Backend-Systemen wie der primären PostgreSQL-Datenbank.

Architektur: Port-Adapter-Muster

Das Modul folgt streng dem Port-Adapter-Muster (auch als Hexagonale Architektur bekannt), um eine saubere Trennung zwischen der Caching-Schnittstelle (dem "Port") und der konkreten Implementierung (dem "Adapter") zu gewährleisten.

infrastructure/cache/ ├── cache-api/ # Der "Port": Definiert die Caching-Schnittstelle └── redis-cache/ # Der "Adapter": Implementiert die Schnittstelle mit Redis

cache-api

Dieses Modul ist der abstrakte Teil der Architektur. Es definiert den "Vertrag" für das Caching, ohne sich um die zugrunde liegende Technologie zu kümmern.

• Zweck: Definiert ein oder mehrere Interfaces, z.B. CacheService, mit generischen Methoden wie get(key), set(key, value, ttl) und evict(key).
• Vorteil: Jeder Service im System programmiert nur gegen dieses Interface. Die Geschäftslogik ist vollständig von der Caching-Technologie entkoppelt. Ein Austausch des Caching-Providers (z.B. von Redis zu Caffeine) würde keine Änderungen in den Fach-Services erfordern.

redis-cache

Dieses Modul ist die konkrete Implementierung der in cache-api definierten Schnittstellen.

• Zweck: Stellt eine Spring-basierte Konfiguration und eine Implementierung des CacheService-Interfaces bereit, die Redis als Datenspeicher verwendet. Es nutzt Spring Data Redis und den Lettuce-Client für die Kommunikation.
• Technologie: Verwendet Jackson für die Serialisierung der zu cachenden Objekte in das JSON-Format, bevor sie in Redis gespeichert werden.
• Vorteil: Kapselt die gesamte Redis-spezifische Logik an einem einzigen Ort.

Verwendung in anderen Modulen

Ein Microservice, der Caching nutzen möchte, geht wie folgt vor:

1. Abhängigkeit deklarieren: Das Service-Modul (z.B. masterdata-service) fügt eine implementation-Abhängigkeit zu :infrastructure:cache:redis-cache in seiner build.gradle.kts hinzu.

   // In masterdata-service/build.gradle.kts
   dependencies {
       implementation(projects.infrastructure.cache.redisCache)
   }
   

2. Interface injizieren: Im Service-Code wird nur das Interface aus cache-api per Dependency Injection angefordert, nicht die konkrete Redis-Klasse.

   // In einem Use Case oder Service
   @Service
   class MasterdataService(
       private val cache: CacheService // Nur das Interface wird verwendet!
   ) {
       fun findCountryById(id: String): Country? {
           val cacheKey = "country:$id"
           // 1. Versuche, aus dem Cache zu lesen
           val cachedCountry = cache.get<Country>(cacheKey)
           if (cachedCountry != null) {
               return cachedCountry
           }
   
           // 2. Wenn nicht im Cache, aus der DB lesen
           val dbCountry = countryRepository.findById(id)
   
           // 3. Ergebnis in den Cache schreiben für zukünftige Anfragen
           if (dbCountry != null) {
               cache.set(cacheKey, dbCountry, ttl = 3600) // Cache für 1 Stunde
           }
           return dbCountry
       }
   }
   

Diese Architektur stellt sicher, dass die Geschäftslogik sauber und von Infrastrukturdetails unberührt bleibt.

---

Letzte Aktualisierung: 31. Juli 2025