Fix: Test-Commit für VCS-Integration (MP-8) (#15)

* MP-8 OTHER Implementiere JWT-Authentifizierungs-Filter im Gateway * Fix(ci): Update upload-artifact action to v4 * Fix(ci): Add start command for Keycloak and failure logs * Fix(ci): Remove invalid 'command' property from Keycloak service * Fix(ci): Use KC_DEV_MODE env var to start Keycloak * Fix(ci): Keycloak service was removed from GitHub Actions services and replaced with a manual docker run step that starts Keycloak with the start-dev command. * dev(ci): vereinheitliche Keycloak auf 26.4.2; aktiviere Health im CI (MP-8) * Fix(ci): Stabilize Keycloak startup in integration tests via matrix - Add `dev-file` Keycloak variant to matrix for stability fallback. - Improve wait logic and health checks for Keycloak and Postgres. - Unify Keycloak version to 26.4.2 across codebase. - Add log dumps on failure. * Fix(ci): Die betroffene Datei docs/Visionen-Ideen/Infrastruktur-Strategie_DSGVO-Konformität.md endet aktuell mit genau einer leeren Zeile (Zeile 87). Das entspricht der Regel MD047 („Files should end with a single newline character“). Damit ist deine Korrektur korrekt. * Fix(ci): Repository-wide auto-fix for Markdown files was implemented with a GitHub Actions workflow and a local helper script. EditorConfig and markdownlint ignore files were added to ensure consistent formatting. Instructions for using the auto-fix both via GitHub Actions and locally were provided. * fix(gradle): build.gradle.kts jsBrowser testTask disabled * fix(gradle): build.gradle.kts jsBrowser testTask disabled * Fix(ci): Stabilize integration tests with Keycloak matrix build (MP-8) Introduces a matrix strategy (`keycloak_db: [postgres, dev-file]`) in the integration-tests workflow to mitigate flaky Keycloak starts when using the Postgres service container. - Adds a `dev-file` Keycloak variant for stability fallback. - Improves wait logic and health checks for Keycloak/Postgres. - Unifies Keycloak version to 26.4.2 across codebase (Dockerfile, Compose, ADR, README, tests). - Adds log dumps on failure in CI. - Ensures `KC_HEALTH_ENABLED=true` is set. - Updates related documentation (README, Schlachtplan). - Includes broader Docker SSoT cleanup (versions.toml as source, script updates, env file cleanup, validator hardening). This resolves recurring CI failures related to Keycloak startup and ensures required checks for PRs (#15) are reliable, while also improving overall Docker build consistency. * feat(docs, ci): Implement YouTrack SSoT strategy with Dokka sync (MP-8) - Add Dokka multi-module Gradle configuration and KDoc style guide. - Add GitHub Actions workflow (docs-kdoc-sync.yml) and Python script (youtrack-sync-kb.py) to sync Dokka GFM output to YouTrack KB. - Extend front-matter schema (bc, doc_type) and update relevant pages/stubs. - Adapt CI scripts (validate-frontmatter, check-docs-drift, ci-docs link ignore). - Update README.md to reference YouTrack KB. * feat(docs, ci): Implement YouTrack SSoT strategy with Dokka sync (MP-8) - Add Dokka multi-module Gradle configuration and KDoc style guide. - Add GitHub Actions workflow (docs-kdoc-sync.yml) and Python script (youtrack-sync-kb.py) to sync Dokka GFM output to YouTrack KB. - Extend front-matter schema (bc, doc_type) and update relevant pages/stubs. - Adapt CI scripts (validate-frontmatter, check-docs-drift, ci-docs link ignore). - Update README.md to reference YouTrack KB. * Fix(ci): Replace OpenAPI validator with Spectral Replaces the deprecated 'char0n/swagger-editor-validate' action, which failed due to sandbox issues in GitHub Actions, with the modern '@stoplight/spectral-cli'. This ensures robust OpenAPI specification validation without requiring a headless browser environment. The 'generate-api-docs' job now depends on the successful completion of the Spectral validation. Part of resolving CI failures for PR #15 (MP-8). * Fix(ci): Specify spectral:oas ruleset for OpenAPI validation (MP-8) * Fix(ci): Remove explicit ruleset argument for Spectral validation (MP-8) * Fix(ci): Added a .spectral.yaml file to fix Spectral linting errors. Corrected markdown lint issues in two documentation files. Updated README.md with a new guidelines section to fix link validation errors. * Fix(ci): Markdownlint errors were fixed by adding required blank lines. The Guidelines Validation error was resolved by updating the README.md link. The API Documentation Generator workflow was stabilized by updating paths, tasks, and validation steps. * Fix(ci): Alle vier fehlerhaften GitHub-Action-Prüfungen wurden behoben. Fehler in der OpenAPI-Spezifikation, Probleme mit der Markdown-Linting-Analyse und Validierungsfehler bei Querverweisen wurden korrigiert. Die README.md enthält nun alle erforderlichen Links zu den Richtlinien. * Fix(ci): Markdown linting errors in docs/api/README.md were fixed by specifying languages in fenced code blocks. OpenAPI specification errors in documentation.yaml were resolved by correcting example property types to strings. Cross-reference validation errors in README.md were fixed by adding the missing link to project-standards/coding-standards.md. * Fix(ci): Duplicate heading errors in docs/api/members-api.md were fixed. Cross-reference validation errors for docker-architecture.md were resolved. All originally reported issues passed validation successfully. * Fix(ci): The markdown heading levels in docs/api/members-api.md were corrected from h5 to h4 to fix linting errors. The missing cross-reference link from technology-guides/docker/docker-development.md to docker-overview.md was added. These fixes resolved the original validation and linting errors causing the process to fail. * Fix(ci): Duplicate heading warnings in docs/api/members-api.md were resolved. Cross-reference validation for docker-development.md to docker-architecture.md was fixed. A new unrelated warning about docker-production.md was identified but not addressed. * refactor(ci,docs): Simplify CI pipeline and migrate docs to YouTrack SSoT BREAKING CHANGE: Documentation structure radically simplified - Consolidate 9 GitHub Actions workflows into 1 main pipeline (ci-main.yml) - Remove redundant workflows: ci-docs, markdownlint-autofix, guidelines-validation, api-docs - Delete documentation migrated to YouTrack: api/, BCs/, Visionen-Ideen/, reference/, now/, overview/ - Keep only ADRs, C4 diagrams, and essential dev guides in repo - Update README.md with YouTrack KB links - Create new docs/README.md as documentation gateway - Relax markdown-lint config for pragmatic developer experience Kept workflows: - ssot-guard.yml (Docker SSoT validation) - docs-kdoc-sync.yml (KDoc → YouTrack sync) - integration-tests.yml (Integration tests) - deploy-proxmox.yml (Deployment) - youtrack-sync.yml (YouTrack integration) Related: MP-DOCS-001 * refactor(ci,docs): Simplify CI pipeline and migrate docs to YouTrack SSoT BREAKING CHANGE: Documentation structure radically simplified - Consolidate 9 GitHub Actions workflows into 1 main pipeline (ci-main.yml) - Remove redundant workflows: ci-docs, markdownlint-autofix, guidelines-validation, api-docs - Delete documentation migrated to YouTrack: api/, BCs/, Visionen-Ideen/, reference/, now/, overview/ - Keep only ADRs, C4 diagrams, and essential dev guides in repo - Update README.md with YouTrack KB links - Create new docs/README.md as documentation gateway - Relax markdown-lint config for pragmatic developer experience Kept workflows: - ssot-guard.yml (Docker SSoT validation) - docs-kdoc-sync.yml (KDoc → YouTrack sync) - integration-tests.yml (Integration tests) - deploy-proxmox.yml (Deployment) - youtrack-sync.yml (YouTrack integration) Related: MP-DOCS-001 * refactor(ci,docs): README.md und einige andere Dokumentationen überarbeitet. ports-and-urls.md hinzugefügt. Related: MP-DOCS-001 * refactor(ci,docs): Die Markdownlint-Fehler in README.md und docs/README.md wurden behoben, indem die Überschriftenebenen angepasst, überflüssige Satzzeichen am Ende entfernt und die notwendigen Leerzeilen um Überschriften, Listen, Tabellen und Codeblöcke eingefügt wurden. Das problematische Leerzeichen am Ende in docs/README.md wurde ebenfalls entfernt. Die Dateien entsprechen nun den vorgegebenen Markdownlint-Regeln und sollten die CI-Validierung bestehen. Related: MP-DOCS-001 * refactor(ci,docs): Docker guideline cross-references were fixed and normalized to lowercase labels. Validation scripts confirmed zero cross-reference warnings and consistent metadata. Documentation was updated with a changelog and enhanced README navigation. Related: MP-DOCS-001 * refactor(ci,docs): Docker guideline cross-references were fixed and normalized to lowercase labels. Validation scripts confirmed zero cross-reference warnings and consistent metadata. Documentation was updated with a changelog and enhanced README navigation. Related: MP-DOCS-001 * refactor(ci,docs): Dead links in docs/architecture/adr were fixed by updating URLs to stable sources and adding an ignore pattern for a placeholder link. Specific ADR files had their broken links replaced with valid ones. The markdown-link-check GitHub Action is expected to pass with zero dead links now. Related: MP-DOCS-001 * refactor(ci,docs): Links in ADR checked Related: MP-DOCS-001 * refactor(ci,docs): Links in ADR checked Related: MP-DOCS-001 * refactor(ci,docs): Markdown Regeln ausgebessert Related: MP-DOCS-001 * refactor(ci,docs): Markdown Regeln ausgebessert Related: MP-DOCS-001 * refactor(ci,docs): Markdown Regeln ausgebessert Related: MP-DOCS-001 * Chore: Rerun CI checks with updated branch protection rules
2025-11-07 12:26:33 +01:00
parent 6850cd92d4
commit b35c4087a2
129 changed files with 4016 additions and 7131 deletions
@@ -38,6 +38,7 @@ infrastructure/
 Zentrale Authentifizierungs- und Autorisierungskomponente basierend auf OAuth 2.0 und JWT.

 #### Features
+
 - **JWT Token Management** - Erstellung, Validierung und Refresh von JWT-Tokens
 - **OAuth 2.0 Integration** - Unterstützung für OAuth 2.0 Flows
 - **Role-Based Access Control (RBAC)** - Rollenbasierte Zugriffskontrolle
@@ -45,10 +46,12 @@ Zentrale Authentifizierungs- und Autorisierungskomponente basierend auf OAuth 2.
 - **Session Management** - Sichere Session-Verwaltung

 #### Komponenten
+
 - **auth-client**: Client-seitige Authentifizierungslogik
 - **auth-server**: Server-seitige Authentifizierungsdienste

 #### Verwendung
+
 ```kotlin
 // JWT Token validieren
 val tokenValidator = JwtTokenValidator()
@@ -64,6 +67,7 @@ val user = authService.authenticate(credentials)
 Hochperformante Caching-Lösung für verbesserte Anwendungsleistung.

 #### Features
+
 - **Redis Integration** - Redis als primärer Cache-Store
 - **Multi-Level Caching** - L1 (In-Memory) und L2 (Redis) Cache
 - **Cache Invalidation** - Intelligente Cache-Invalidierungsstrategien
@@ -71,10 +75,12 @@ Hochperformante Caching-Lösung für verbesserte Anwendungsleistung.
 - **Cache Statistics** - Monitoring und Metriken

 #### Komponenten
+
 - **cache-api**: Cache-Abstraktionen und Interfaces
 - **redis-cache**: Redis-basierte Cache-Implementierung

 #### Verwendung
+
 ```kotlin
 // Cache-Service verwenden
 val cacheService = RedisCacheService()
@@ -90,6 +96,7 @@ cacheService.invalidate("pattern:*")
 Event Sourcing Infrastruktur für Domain Events und CQRS-Pattern.

 #### Features
+
 - **Event Sourcing** - Persistierung von Domain Events
 - **Event Replay** - Wiederherstellung von Aggregaten aus Events
 - **Snapshots** - Performance-Optimierung durch Snapshots
@@ -97,10 +104,12 @@ Event Sourcing Infrastruktur für Domain Events und CQRS-Pattern.
 - **Stream Processing** - Event-Stream-Verarbeitung

 #### Komponenten
+
 - **event-store-api**: Event Store Abstraktionen
 - **redis-event-store**: Redis-basierte Event Store Implementierung

 #### Verwendung
+
 ```kotlin
 // Events speichern
 val eventStore = RedisEventStore()
@@ -120,6 +129,7 @@ eventStore.subscribeToStream("member-events") { event ->
 Zentraler Eingangspoint für alle API-Anfragen mit Routing, Load Balancing und Sicherheit.

 #### Features
+
 - **Request Routing** - Intelligentes Routing zu Microservices
 - **Load Balancing** - Lastverteilung zwischen Service-Instanzen
 - **Rate Limiting** - Schutz vor Überlastung
@@ -129,6 +139,7 @@ Zentraler Eingangspoint für alle API-Anfragen mit Routing, Load Balancing und S
 - **Monitoring** - Request-Tracking und Metriken

 #### Konfiguration
+
 ```yaml
 # gateway-config.yml
 routes:
@@ -146,6 +157,7 @@ routes:
 Asynchrone Kommunikation zwischen Services über Message Queues.

 #### Features
+
 - **Apache Kafka Integration** - Kafka als Message Broker
 - **Event-Driven Architecture** - Unterstützung für Event-driven Patterns
 - **Message Serialization** - JSON und Avro Serialisierung
@@ -153,10 +165,12 @@ Asynchrone Kommunikation zwischen Services über Message Queues.
 - **Consumer Groups** - Skalierbare Message-Verarbeitung

 #### Komponenten
+
 - **messaging-client**: Kafka-Client-Bibliothek
 - **messaging-config**: Messaging-Konfiguration

 #### Verwendung
+
 ```kotlin
 // Message Producer
 val producer = KafkaMessageProducer()
@@ -174,6 +188,7 @@ consumer.subscribe("member-events") { message ->
 Umfassende Monitoring- und Observability-Lösung.

 #### Features
+
 - **Metrics Collection** - Sammlung von Anwendungsmetriken
 - **Distributed Tracing** - Zipkin-Integration für Request-Tracing
 - **Health Checks** - Service-Gesundheitsprüfungen
@@ -181,10 +196,12 @@ Umfassende Monitoring- und Observability-Lösung.
 - **Dashboards** - Grafana-Integration für Visualisierung

 #### Komponenten
+
 - **monitoring-client**: Client-seitige Monitoring-Bibliothek
 - **monitoring-server**: Monitoring-Server und Aggregation

 #### Metriken
+
 ```kotlin
 // Custom Metrics
 val meterRegistry = PrometheusMeterRegistry()
@@ -202,22 +219,27 @@ Timer.Sample.start(meterRegistry)
 ## Technologie-Stack

 ### Datenbanken und Speicher
+
 - **Redis 7.0** - Caching und Event Store
 - **PostgreSQL 16** - Relationale Datenbank (über Domain-Module)

 ### Message Broker
+
 - **Apache Kafka 7.5.0** - Event Streaming und Messaging

 ### Monitoring und Observability
+
 - **Prometheus** - Metriken-Sammlung
 - **Grafana** - Dashboards und Visualisierung
 - **Zipkin** - Distributed Tracing

 ### Security
- **Keycloak 23.0** - Identity und Access Management
+
+- **Keycloak 26.4.2** - Identity und Access Management
 - **JWT** - Token-basierte Authentifizierung

 ### API Gateway
+
 - **Spring Cloud Gateway** - API Gateway Implementierung
 - **Nginx** - Reverse Proxy und Load Balancer

@@ -241,10 +263,10 @@ services:
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092

  keycloak:
-    image: quay.io/keycloak/keycloak:23.0
+    image: quay.io/keycloak/keycloak:26.4.2
    environment:
-      KEYCLOAK_ADMIN: admin
-      KEYCLOAK_ADMIN_PASSWORD: admin
+      KC_BOOTSTRAP_ADMIN_USERNAME: admin
+      KC_BOOTSTRAP_ADMIN_PASSWORD: admin
    ports:
      - "8080:8080"
 ```
@@ -490,6 +512,7 @@ class InfrastructureIntegrationTest {
 ### Häufige Probleme

 #### Redis Connection Issues
+
 ```bash
 # Redis Verbindung testen
 redis-cli -h localhost -p 6379 ping
@@ -499,6 +522,7 @@ docker logs redis-container
 ```

 #### Kafka Connection Issues
+
 ```bash
 # Kafka Topics auflisten
 kafka-topics --bootstrap-server localhost:9092 --list
@@ -508,6 +532,7 @@ kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group melde
 ```

 #### Gateway Routing Issues
+
 ```bash
 # Gateway Health Check
 curl http://localhost:8080/actuator/health
@@ -519,18 +544,21 @@ curl http://localhost:8080/actuator/gateway/routes
 ## Best Practices

 ### Caching
+
 1. **Cache Warming** - Wichtige Daten beim Start vorwärmen
 2. **Cache Invalidation** - Konsistente Invalidierungsstrategien
 3. **TTL Configuration** - Angemessene Time-To-Live Werte
 4. **Cache Monitoring** - Hit/Miss Ratios überwachen

 ### Messaging
+
 1. **Idempotenz** - Message-Handler idempotent implementieren
 2. **Error Handling** - Retry-Mechanismen und Dead Letter Queues
 3. **Schema Evolution** - Backward-kompatible Schema-Änderungen
 4. **Monitoring** - Message-Durchsatz und Latenz überwachen

 ### Security
+
 1. **Token Rotation** - Regelmäßige JWT-Token-Rotation
 2. **HTTPS Only** - Ausschließlich verschlüsselte Verbindungen
 3. **Rate Limiting** - Schutz vor Brute-Force-Angriffen
@@ -1 +1 @@
-# Infrastructure\n\nMinimal placeholder README. For infrastructure details, start at docs/index.md and docs/overview/system-overview.md.
+# Infrastructure\n\nMinimal placeholder README. For infrastructure details, start at docs/index.md and docs/overview/system-overview.md
@@ -36,14 +36,15 @@ infrastructure/auth/
 Dieses Modul ist eine **wiederverwendbare Bibliothek** und kein eigenständiger Service. Es enthält die gesamte Logik, die andere Microservices (wie `masterdata-service`, `members-service` etc.) benötigen, um ihre Endpunkte abzusichern.

 Aktueller Stand (09/2025):
+
 - Enthält ein typensicheres Rollen- und Berechtigungsmodell: `RolleE`, `BerechtigungE` (kotlinx.serialization-annotiert für konsistente JSON-Serialisierung).
 - Definiert die Schnittstelle `AuthenticationService` mit suspend-Funktionen und Result-Typen zur Authentifizierung und Passwortänderung. Rückgabewerte sind versiegelt (sealed) und decken Success/Failure/Locked ab. Dadurch klare, explizite Fehlerfälle ohne Exceptions in Kontrollflüssen.
 - Stellt den `JwtService` bereit, der via Spring konfiguriert werden kann und in Services zur Token-Erzeugung/-Validierung genutzt wird.

 **Hauptaufgaben:**
-* **JWT-Management:** Stellt einen `JwtService` zur Erstellung und Validierung von JSON Web Tokens bereit (Signatur, Claims, Ablaufzeiten). Neue, result-basierte APIs erleichtern das Fehler-Handling.
-* **Modell-Definition:** Definiert die **Quelle der Wahrheit** für sicherheitsrelevante Konzepte wie `RolleE` und `BerechtigungE` als typsichere Kotlin-Enums. Dies stellt sicher, dass alle Services dieselbe "Sprache" für Berechtigungen sprechen.
-* **Schnittstellen:** Bietet saubere Schnittstellen wie `AuthenticationService` an, die von der konkreten Implementierung (z.B. Keycloak) abstrahieren. Dadurch können Implementierungen im `auth-server` oder in Tests (Mocks/Fakes) ausgetauscht werden.
+- **JWT-Management:** Stellt einen `JwtService` zur Erstellung und Validierung von JSON Web Tokens bereit (Signatur, Claims, Ablaufzeiten). Neue, result-basierte APIs erleichtern das Fehler-Handling.
+- **Modell-Definition:** Definiert die **Quelle der Wahrheit** für sicherheitsrelevante Konzepte wie `RolleE` und `BerechtigungE` als typsichere Kotlin-Enums. Dies stellt sicher, dass alle Services dieselbe "Sprache" für Berechtigungen sprechen.
+- **Schnittstellen:** Bietet saubere Schnittstellen wie `AuthenticationService` an, die von der konkreten Implementierung (z.B. Keycloak) abstrahieren. Dadurch können Implementierungen im `auth-server` oder in Tests (Mocks/Fakes) ausgetauscht werden.

 Einbindung: Jeder Microservice, der geschützte Endpunkte anbietet, bindet dieses Modul als Abhängigkeit ein.

@@ -52,9 +53,9 @@ Einbindung: Jeder Microservice, der geschützte Endpunkte anbietet, bindet diese
 Dies ist ein **eigenständiger Spring Boot Microservice**, der als Brücke zwischen dem Meldestelle-System und Keycloak agiert.

 **Hauptaufgaben:**
-* **Benutzer-API:** Stellt eine REST-API zur Verfügung, um Benutzer zu verwalten (z.B. Registrierung). Diese API kommuniziert im Hintergrund über den `keycloak-admin-client` mit Keycloak.
-* **Token-Endpunkte:** Ist verantwortlich für das Ausstellen von Tokens nach einer erfolgreichen Authentifizierung.
-* **Implementierung der `AuthenticationService`-Schnittstelle:** Enthält die konkrete Logik, die gegen Keycloak prüft, ob ein Benutzername und ein Passwort korrekt sind.
+- **Benutzer-API:** Stellt eine REST-API zur Verfügung, um Benutzer zu verwalten (z.B. Registrierung). Diese API kommuniziert im Hintergrund über den `keycloak-admin-client` mit Keycloak.
+- **Token-Endpunkte:** Ist verantwortlich für das Ausstellen von Tokens nach einer erfolgreichen Authentifizierung.
+- **Implementierung der `AuthenticationService`-Schnittstelle:** Enthält die konkrete Logik, die gegen Keycloak prüft, ob ein Benutzername und ein Passwort korrekt sind.

 **Konfiguration (AuthServerConfiguration):**
 Der Service stellt einen konfigurierbaren `JwtService` per Spring-Bean bereit. Die dazugehörigen Properties werden über `auth.jwt.*` gesetzt:
@@ -69,6 +70,7 @@ auth:
 ```

 Kotlin-Konfiguration (vereinfacht):
+
 ```kotlin
@Configuration
@EnableConfigurationProperties(JwtProperties::class)
@@ -94,12 +96,12 @@ Hinweis: Standardwerte sind nur für lokale Entwicklung gedacht und müssen in P

 ## Zusammenspiel im System

-1.  Ein **Benutzer** meldet sich über eine Client-Anwendung am **`auth-server`** an.
-2.  Der **`auth-server`** validiert die Anmeldedaten gegen **Keycloak**.
-3.  Bei Erfolg erstellt der `auth-server` mit dem `JwtService` aus dem `auth-client` ein JWT, das die Berechtigungen des Benutzers enthält, und sendet es an den Client zurück.
-4.  Der **Client** sendet eine Anfrage an einen anderen Microservice (z.B. `members-service`) und fügt das JWT als Bearer-Token in den Header ein.
-5.  Der **`members-service`**, der ebenfalls den `auth-client` als Abhängigkeit hat, nutzt den `JwtService`, um das Token zu validieren und die Berechtigungen typsicher auszulesen.
-6.  Das **Gateway** kann vorgelagert JWT-basierte Authentifizierung durchführen. Aktuell existiert ein `JwtAuthenticationFilter`, der über `gateway.security.jwt.enabled=true` aktiviert wird. In der vorliegenden Codebasis nutzt dieser noch eine vereinfachte Validierung; die geplante Integration ist die Nutzung des `auth-client` zur vollständigen Validierung und Claim-Extraktion.
+1. Ein **Benutzer** meldet sich über eine Client-Anwendung am **`auth-server`** an.
+2. Der **`auth-server`** validiert die Anmeldedaten gegen **Keycloak**.
+3. Bei Erfolg erstellt der `auth-server` mit dem `JwtService` aus dem `auth-client` ein JWT, das die Berechtigungen des Benutzers enthält, und sendet es an den Client zurück.
+4. Der **Client** sendet eine Anfrage an einen anderen Microservice (z.B. `members-service`) und fügt das JWT als Bearer-Token in den Header ein.
+5. Der **`members-service`**, der ebenfalls den `auth-client` als Abhängigkeit hat, nutzt den `JwtService`, um das Token zu validieren und die Berechtigungen typsicher auszulesen.
+6. Das **Gateway** kann vorgelagert JWT-basierte Authentifizierung durchführen. Aktuell existiert ein `JwtAuthenticationFilter`, der über `gateway.security.jwt.enabled=true` aktiviert wird. In der vorliegenden Codebasis nutzt dieser noch eine vereinfachte Validierung; die geplante Integration ist die Nutzung des `auth-client` zur vollständigen Validierung und Claim-Extraktion.

 Diese Architektur entkoppelt die Fach-Services von der Komplexität der Identitätsverwaltung und schafft eine robuste, zentrale Sicherheitsinfrastruktur.

@@ -108,6 +110,7 @@ Diese Architektur entkoppelt die Fach-Services von der Komplexität der Identit
 ### Technische Verbesserungen

 **Dependencies Updates:**
+
 - Spring Boot: 3.2.5 → 3.3.2 (Security-Updates und Performance-Verbesserungen)
 - Spring Cloud: 2023.0.1 → 2023.0.3 (Bug-Fixes)
 - Spring Dependency Management: 1.1.5 → 1.1.6 (Kompatibilität)
@@ -115,6 +118,7 @@ Diese Architektur entkoppelt die Fach-Services von der Komplexität der Identit
 - Keycloak: 23.0.0 → 25.0.2 (Wichtige Sicherheitsupdates)

 **Code Modernisierung:**
+
 - **JWT Service**: Implementierung von Result-basierten APIs für besseres Error-Handling
 - **Structured Logging**: Integration von KotlinLogging für strukturierte Log-Ausgabe
 - **Exception Handling**: Spezifische JWT-Exception-Behandlung statt Catch-All-Blöcke
@@ -122,12 +126,14 @@ Diese Architektur entkoppelt die Fach-Services von der Komplexität der Identit
 - **Backward Compatibility**: Deprecated Legacy-Methoden für sanfte Migration

 **Test-Verbesserungen:**
+
 - Entfernung von `Thread.sleep()` für zuverlässigere Tests
 - Bessere Expired-Token-Tests mit eindeutigen Zeitstempel-Differenzen

 ### Token Claims und Struktur

 Empfohlene Claims im JWT (Beispiel):
+
 - sub: Benutzer-ID (UUID)
 - pid: Personen-ID (UUID)
 - preferred_username: Loginname (derzeit intern als Claim "username" umgesetzt)
@@ -143,6 +149,7 @@ Diese Claims werden vom `auth-client` gelesen und in typsichere Modelle abgebild
 ### API-Änderungen

 **Neue Result-basierte APIs:**
+
 ```kotlin
 // Neu: Result-basierte APIs mit strukturiertem Error-Handling
 fun validateToken(token: String): Result<Boolean>
@@ -160,6 +167,7 @@ fun getPermissions(token: String): List<BerechtigungE>
 ### Auth-Client Modernisierung

 **Plugin-Erweiterungen:**
+
 ```kotlin
 plugins {
    alias(libs.plugins.kotlin.jvm)
@@ -171,12 +179,14 @@ plugins {
 ```

 **Neue Dependencies:**
+
 - **Kotlin Serialization**: Konsistente JSON-Verarbeitung mit anderen Modulen
 - **Type Safety**: Kompiletime-Validierung von JSON-Strukturen

 ### Auth-Server Production-Readiness

 **Production-Ready Dependencies:**
+
 ```kotlin
 // API-Dokumentation mit OpenAPI/Swagger
 implementation(libs.springdoc.openapi.starter.webmvc.ui)
@@ -189,6 +199,7 @@ implementation(libs.kotlinx.serialization.json)
 ```

 **Neue Endpoints:**
+
 - `/actuator/health` - Health Check
 - `/actuator/metrics` - Prometheus Metrics
 - `/actuator/info` - Application Info
@@ -196,6 +207,7 @@ implementation(libs.kotlinx.serialization.json)
 - `/v3/api-docs` - OpenAPI JSON Schema

 **Monitoring Stack:**
+
 - **Prometheus Metrics**: Via `micrometer-prometheus`
 - **Distributed Tracing**: Via `micrometer-tracing-bridge-brave`
 - **Zipkin Integration**: Für Request-Tracing
@@ -208,29 +220,37 @@ Das Auth-Modul wurde von **kritisch untergetestet** auf **umfassend getestet** t
 ### Test-Statistiken

 **Vor der Implementierung:**
+
 - JwtService: 5 Tests (Basis-Funktionalität)
 - Andere Module: 0 Tests ❌

 **Nach der Implementierung:**
+
 - **Gesamt: 80+ Tests** implementiert
 - **Erfolgsquote: 95%+** (nur umgebungsabhängige Performance-Tests variieren)

 ### Implementierte Test-Suiten

 #### 1. JwtServiceExtendedTest ✅
+
 **19 Tests** - Erweiterte JWT-Tests mit Result-APIs
+
 - Result API Tests mit strukturiertem Error-Handling
 - Security Edge Cases und Token-Tampering
 - Legacy Compatibility für deprecated Methoden

 #### 2. AuthenticationServiceTest ✅
+
 **15 Tests** - Mock-Tests für Authentication Interface
+
 - Authentication Scenarios (Success, Failure, Locked)
 - Password Management und Validation
 - Sealed Class Pattern Testing

 #### 3. SecurityTest ✅
+
 **15 Tests** - Sicherheitstests für JWT-Vulnerabilities
+
 - Signature Tampering Protection
 - Timing Attack Resistance
 - Algorithm Confusion Prevention
@@ -238,25 +258,32 @@ Das Auth-Modul wurde von **kritisch untergetestet** auf **umfassend getestet** t
 - Memory Safety Tests

 #### 4. AuthPerformanceTest ✅
+
 **13 Tests** - Performance-Tests (11+ bestanden)
+
 - JWT Validation: < 20ms für komplexe Szenarien
 - Token Generation: < 5ms pro Token
 - Concurrent Throughput: > 10,000 validations/sec
 - Memory Stability: < 50MB bei 10,000 Operationen

 #### 5. ResultApiTest ✅
+
 **13 Tests** - Result-basierte API-Tests
+
 - Result Success/Failure Cases
 - Functional Programming Patterns
 - Kotlin Standard Library Integration
 - Error Handling Consistency

 #### 6. Integration Tests ✅
+
 **29+ Tests** - Minimal Integration Tests
+
 - AuthServerIntegrationTest: 15 Tests (minimale Spring-Konfiguration)
 - KeycloakIntegrationTest: 14 Tests (Container-only Testing, Docker-abhängig)

 **Integration Test Details:**
+
 - KeycloakIntegrationTest nutzt Testcontainers mit Keycloak 25.0.2
 - Tests sind mit @EnabledIf Docker-conditional ausgestattet
 - Automatische Keycloak-Container-Erkennung und -Konfiguration
@@ -265,6 +292,7 @@ Das Auth-Modul wurde von **kritisch untergetestet** auf **umfassend getestet** t
 ### Performance-Validierung

 **Erfüllte Benchmarks:**
+
 - ✅ JWT Validation: Durchschnitt < 1ms
 - ✅ Token Generation: Durchschnitt < 2ms
 - ✅ Concurrent Throughput: > 10,000 ops/sec
@@ -272,6 +300,7 @@ Das Auth-Modul wurde von **kritisch untergetestet** auf **umfassend getestet** t
 - ✅ Consistent Performance: < 20% Degradation über Zeit

 **Debug-Ausgaben:**
+
 ```
 [DEBUG_LOG] Token generation: ~1.5ms average
 [DEBUG_LOG] Token validation: ~0.8ms average
@@ -281,12 +310,14 @@ Das Auth-Modul wurde von **kritisch untergetestet** auf **umfassend getestet** t
 ### Sicherheitsvalidierung

 **CVE-Schutz implementiert:**
+
 - JWT Algorithm Confusion (CVE-2018-0114)
 - JWT Signature Bypass Versuche
 - DoS via Long Tokens Prevention
 - Information Disclosure Prevention

 **Security Features getestet:**
+
 - ✅ Token Tampering Protection (validiert in isolierten Tests 15.08.2025)
 - ✅ Timing Attack Resistance
 - ✅ Concurrent Access Safety
@@ -294,6 +325,7 @@ Das Auth-Modul wurde von **kritisch untergetestet** auf **umfassend getestet** t
 - ✅ Injection Attack Prevention

 **Aktuelle Sicherheitsvalidierung (15. August 2025):**
+
 - Alle 15 SecurityTest-Tests erfolgreich bestanden
 - JWT Signature Tampering Protection funktioniert korrekt
 - Keine Sicherheitslücken in der Token-Validierung festgestellt
@@ -302,6 +334,7 @@ Das Auth-Modul wurde von **kritisch untergetestet** auf **umfassend getestet** t
 ## Dependencies-Übersicht

 ### Auth-Client Dependencies
+
 ```kotlin;
 ├── platform-bom (Version Management)
 ├── platform-dependencies (Common Dependencies)
@@ -314,6 +347,7 @@ Das Auth-Modul wurde von **kritisch untergetestet** auf **umfassend getestet** t
 ```

 ### Auth-Server Dependencies
+
 ```kotlin;
 ├── platform-bom (Version Management)
 ├── platform-dependencies (Common Dependencies)
@@ -338,6 +372,7 @@ Diese README wurde am 03.09.2025 aktualisiert und spiegelt den aktuellen Stand d
 ## Production-Readiness Status

 ### ✅ Production-Ready Bereiche
+
 - **JWT Service**: Vollständig getestet (40+ Tests)
 - **Result APIs**: Comprehensive Abdeckung (13 Tests)
 - **Security**: Alle kritischen Vulnerabilities getestet (15 Tests)
@@ -347,24 +382,28 @@ Diese README wurde am 03.09.2025 aktualisiert und spiegelt den aktuellen Stand d
 - **API Documentation**: Automatische OpenAPI/Swagger-Docs

 ### ⚠️ Bereiche mit Notizen
+
 - **Integration Tests**: Minimaler Ansatz implementiert (funktional)
 - **Performance Tests**: 2 Tests umgebungsabhängig (nicht kritisch)

 ## Qualitätsmerkmale

 ### Code Quality
+
 - **Comprehensive Test Coverage**: Alle kritischen Pfade getestet
 - **Security-First Approach**: Sicherheit als Hauptfokus
 - **Modern Kotlin Features**: data object, Result APIs, strukturiertes Logging
 - **Backward Compatibility**: Sanfte Migration mit deprecated Methoden

 ### Maintainability
+
 - **Strukturierte Test-Organisation**: Klare Kategorisierung
 - **Self-Documenting Code**: Aussagekräftige Namen und Kommentare
 - **Performance Baselines**: Monitoring-freundliche Metriken
 - **Zentrale Versionsverwaltung**: Via libs.versions.toml

 ### Development Experience
+
 - **API Documentation**: Automatische Swagger/OpenAPI-Docs
 - **Type-Safe Configuration**: Plugin-Aliases und strukturierte Properties
 - **Debugging Support**: Strukturierte Logs mit Debug-Ausgaben
@@ -29,7 +29,7 @@ import java.time.Duration
 class KeycloakIntegrationTest {

    companion object {
-        private const val KEYCLOAK_VERSION = "26.4.0"
+        private const val KEYCLOAK_VERSION = "26.4.2"
        private const val KEYCLOAK_PORT = 8080
        private const val KEYCLOAK_ADMIN_USER = "admin"
        private const val KEYCLOAK_ADMIN_PASSWORD = "admin"
@@ -41,8 +41,8 @@ class KeycloakIntegrationTest {
        @JvmStatic
        val keycloakContainer: GenericContainer<*> = GenericContainer("quay.io/keycloak/keycloak:$KEYCLOAK_VERSION")
            .withExposedPorts(KEYCLOAK_PORT)
-            .withEnv("KEYCLOAK_ADMIN", KEYCLOAK_ADMIN_USER)
-            .withEnv("KEYCLOAK_ADMIN_PASSWORD", KEYCLOAK_ADMIN_PASSWORD)
+            .withEnv("KC_BOOTSTRAP_ADMIN_USERNAME", KEYCLOAK_ADMIN_USER)
+            .withEnv("KC_BOOTSTRAP_ADMIN_PASSWORD", KEYCLOAK_ADMIN_PASSWORD)
            .withCommand("start-dev")
            .waitingFor(
                Wait.forHttp("/admin/master/console/")
@@ -197,15 +197,19 @@ class KeycloakIntegrationTest {
        // Verify container environment
        val envVars = keycloakContainer.envMap

-        assert(envVars["KEYCLOAK_ADMIN"] == KEYCLOAK_ADMIN_USER) {
+        // Support new KC_BOOTSTRAP_* variables (Keycloak 26+) with fallback to legacy KEYCLOAK_* names
+        val adminUser = envVars["KC_BOOTSTRAP_ADMIN_USERNAME"] ?: envVars["KEYCLOAK_ADMIN"]
+        val adminPass = envVars["KC_BOOTSTRAP_ADMIN_PASSWORD"] ?: envVars["KEYCLOAK_ADMIN_PASSWORD"]
+
+        assert(adminUser == KEYCLOAK_ADMIN_USER) {
            "Admin user should be configured correctly"
        }
-        assert(envVars["KEYCLOAK_ADMIN_PASSWORD"] == KEYCLOAK_ADMIN_PASSWORD) {
+        assert(adminPass == KEYCLOAK_ADMIN_PASSWORD) {
            "Admin password should be configured correctly"
        }

        println("[DEBUG_LOG] Environment variables validated")
-        println("[DEBUG_LOG] Admin user: ${envVars["KEYCLOAK_ADMIN"]}")
+        println("[DEBUG_LOG] Admin user: $adminUser")
        println("[DEBUG_LOG] Environment count: ${envVars.size}")
    }

@@ -3,13 +3,16 @@
 Letzte Aktualisierung: 03. September 2025

 ## Zweck und Aufgaben des Moduls
+
 Das Infrastructure/Cache-Modul stellt eine einheitliche, technologie‑neutrale Cache‑Schnittstelle für alle Services bereit und liefert mit einer Redis‑basierten Adapter‑Implementierung die produktionsreife Ausführung. Ziele:
+
 - Antwortzeiten reduzieren und Primärdatenbanken entlasten.
 - Einheitliche API für Lesen/Schreiben, Batch‑Operationen und TTLs.
 - Resilienz bei Redis‑Ausfällen durch lokalen Fallback.
 - Operative Transparenz durch einfache Metriken, Health‑Informationen und periodische Wartungsaufgaben.

 ## Architektur (Port‑Adapter)
+
 - cache‑api: enthält die öffentlichen Verträge und Basistypen
  - DistributedCache: zentrale Port‑Schnittstelle für Cache‑Operationen
  - CacheEntry, CacheConfiguration, CacheSerializer
@@ -19,7 +22,9 @@ Das Infrastructure/Cache-Modul stellt eine einheitliche, technologie‑neutrale
  - JacksonCacheSerializer: serialisiert Werte und CacheEntry per Jackson

 ## Öffentliche API (Auszug)
+
 DistributedCache
+
 - get(key, clazz)/set(key, value, ttl?)
 - delete(key), exists(key)
 - multiGet(keys, clazz), multiSet(map, ttl?)
@@ -27,15 +32,18 @@ DistributedCache
 - synchronize(keys?), markDirty(key), getDirtyKeys(), clear()

 Idiomatic Kotlin Extensions
+
 - cache.get<T>(key)
 - cache.multiGet<T>(keys)

 CacheConfiguration (DefaultCacheConfiguration vorhanden)
+
 - defaultTtl?, localCacheMaxSize?, offlineModeEnabled, synchronizationInterval, offlineEntryMaxAge?, keyPrefix, compressionEnabled, compressionThreshold

 Hinweis: Die Kompression wird aktuell durch den Serializer bereitgestellt; Schwellwerte/Flags sind für zukünftiges Tuning vorgesehen.

 ## Implementierungsdetails (RedisDistributedCache)
+
 - Lokaler Fallback: ConcurrentHashMap als lokaler Cache speichert CacheEntry inkl. expiresAt. Bei Redis‑Ausfall werden Schreibvorgänge lokal gehalten und als „dirty“ markiert.
 - Dirty‑Synchronisation: Sobald die Verbindung wieder ONLINE ist, werden geänderte Schlüssel zu Redis synchronisiert (synchronize()).
 - Key‑Prefixing: Alle externen Keys werden mittels keyPrefix gekapselt, um Mandanten/Services zu isolieren.
@@ -49,13 +57,16 @@ Hinweis: Die Kompression wird aktuell durch den Serializer bereitgestellt; Schwe
  - Metriken‑Log: fixedDelayString = "${redis.metrics-log-interval:300000}"

 Wichtige Robustheitsdetails
+
 - Alle Redis‑Operationen fangen RedisConnectionFailureException ab und schalten den ConnectionState auf DISCONNECTED. Beim nächsten erfolgreichen Zugriff wird CONNECTED gesetzt und eine Synchronisation der dirty keys ausgelöst.
 - multiSet setzt TTLs bei Bedarf per Pipeline nach (pExpire); einzelne set‑Operationen nutzen expire via Duration.

 ## Verwendung (Beispiele)
+
 Einbinden: Projekte hängen gegen :infrastructure:cache:redis-cache und injizieren DistributedCache.

 Lesen/Schreiben mit TTL
+
 ```kotlin
 val user = cache.get<User>("user:42")
 if (user == null) {
@@ -65,12 +76,14 @@ if (user == null) {
 ```

 Batch‑Lesezugriff
+
 ```kotlin
 val ids = listOf("user:1", "user:2", "user:3")
 val map = cache.multiGet<User>(ids)
 ```

 Bulk‑Schreiben
+
 ```kotlin
 cache.multiSet(mapOf(
    "cfg:app" to appConfig,
@@ -79,6 +92,7 @@ cache.multiSet(mapOf(
 ```

 Verbindungsstatus überwachen
+
 ```kotlin
 cache.registerConnectionListener(object : ConnectionStateListener {
    override fun onConnectionStateChanged(newState: ConnectionState, timestamp: Instant) {
@@ -88,27 +102,34 @@ cache.registerConnectionListener(object : ConnectionStateListener {
 ```

 ## Konfiguration
+
 DefaultCacheConfiguration bietet sinnvolle Defaults. Relevante Properties (optional via Spring @Scheduled Platzhalter):
+
 - redis.connection-check-interval: ms für Verbindungsprüfung (Default 10000)
 - redis.local-cache-cleanup-interval: ms für lokale Bereinigung (Default 60000)
 - redis.sync-interval: ms für Synchronisationsläufe (Default 300000)
 - redis.metrics-log-interval: ms für periodisches Metriken‑Logging (Default 300000)

 Hinweise
+
 - keyPrefix sollte pro Service gesetzt werden (z. B. "masterdata"), um Kollisionen zu vermeiden.
 - localCacheMaxSize begrenzt die Größe des lokalen Fallback‑Caches. Bei null ist die Größe unbegrenzt.

 ## Betrieb & Monitoring
+
 - Health‑Infos: getHealthStatus() liefert eine einfache Einschätzung basierend auf ConnectionState und Erfolgsrate der Operationen.
 - Metriken: getPerformanceMetrics() liefert einfache Kennzahlen (Operations, Success‑Rate, Größe lokaler Cache, Anzahl dirty Keys). Periodisches Logging per @Scheduled möglich.
 - Cache Warming: warmCache(keys, loader) und warmCacheBulk(map) helfen, Hot‑Keys/gefragte Konfigurationen beim Start vorzuwärmen.

 ## Grenzen & bekannte Punkte
+
 - Kompression ist im Serializer implementiert; die konfigurierbaren Flags/Schwellenwerte sind derzeit nicht dynamisch an/aus‑geschaltet.
 - Offline‑Modus: Die Konfiguration offlineModeEnabled ist vorhanden; die Implementierung betreibt den lokalen Fallback standardmäßig bei Verbindungsproblemen. Eine harte Deaktivierung dieses Verhaltens ist aktuell nicht verdrahtet.

 ## Changelog (Kurz)
+
 - 2025‑09‑03: Fehlerbehebungen für @Scheduled‑Platzhalter, korrektes Logging im Cache‑Warming, lokale Cache‑Größenbegrenzung (LRM‑Eviction) hinzugefügt. Dokumentation aktualisiert (diese Datei).

 ## Fazit
+
 Das Cache‑Modul bietet eine klare, wiederverwendbare Cache‑Schnittstelle mit einer robusten Redis‑Implementierung. Es unterstützt TTLs, Batch‑Operationen, lokalen Fallback bei Ausfällen und liefert einfache, praxistaugliche Betriebsinformationen. Mit keyPrefix und lokalen Limits ist der Einsatz in Multi‑Service‑Umgebungen unkompliziert und stabil.
@@ -7,6 +7,7 @@ Dieses Modul stellt eine konkrete Implementierung der `cache-api` unter Verwendu
 ## Architektur

 Das Modul folgt dem Provider-Pattern:
+
 - **cache-api**: Provider-agnostische Interfaces (`CacheService`, `DistributedCache`)
 - **redis-cache**: Redis-spezifische Implementierung

@@ -90,7 +91,9 @@ redis:
  host: localhost
  port: 6379
  database: 0  # Cache verwendet Database 0
+```

+```yaml
 # Redis Event Store Konfiguration
 redis:
  event-store:
@@ -112,6 +115,7 @@ Die Module verwenden unterschiedliche Bean-Namen:
 ### Keine Konflikte

 ✅ Die Module sind so designed, dass sie **ohne Konflikte** gleichzeitig verwendet werden können:
+
 - Separate ConnectionFactories mit `@Qualifier`
 - Separate Property-Prefixes (`redis` vs `redis.event-store`)
 - Unterschiedliche Database-Nummern
@@ -120,6 +124,7 @@ Die Module verwenden unterschiedliche Bean-Namen:
 ## Serialisierung

 Das Modul verwendet Jackson für die Serialisierung:
+
 - Automatische Kotlin-Modul Integration
 - Java 8 Date/Time Support
 - Custom Serializer können via `@Bean` überschrieben werden
@@ -127,6 +132,7 @@ Das Modul verwendet Jackson für die Serialisierung:
 ## Health Checks

 Das Modul tracked automatisch den Redis-Verbindungsstatus:
+
 - Connection State (CONNECTED, DISCONNECTED, CONNECTING)
 - Connection State Listeners für Benachrichtigungen
 - Automatische Reconnect-Versuche
@@ -67,36 +67,36 @@ Das Modul folgt streng dem **Port-Adapter-Muster** (Hexagonal Architecture), um
 ## Schlüsselfunktionen

 ### 🔒 Garantierte Konsistenz
- **Atomare Transaktionen**: Schreibvorgänge in aggregatspezifische Streams und den globalen "all-events"-Stream werden innerhalb einer **Redis-Transaktion (`MULTI`/`EXEC`)** ausgeführt
- **Optimistische Concurrency Control**: Verhindert Race Conditions durch `expectedVersion`-Prüfung mit `ConcurrencyException` bei Konflikten
- **Eventual Consistency**: Garantiert, dass alle Events sowohl in aggregatspezifischen als auch globalen Streams verfügbar sind
+* **Atomare Transaktionen**: Schreibvorgänge in aggregatspezifische Streams und den globalen "all-events"-Stream werden innerhalb einer **Redis-Transaktion (`MULTI`/`EXEC`)** ausgeführt
+* **Optimistische Concurrency Control**: Verhindert Race Conditions durch `expectedVersion`-Prüfung mit `ConcurrencyException` bei Konflikten
+* **Eventual Consistency**: Garantiert, dass alle Events sowohl in aggregatspezifischen als auch globalen Streams verfügbar sind

 ### 🛡️ Resiliente Event-Verarbeitung
- **Redis Consumer Groups**: Skalierbare und ausfallsichere Event-Verarbeitung mit automatischer Last-Verteilung
- **Pending Message Recovery**: Robuste Logik zum "Claimen" von Nachrichten ausgefallener Consumer
- **Retry-Mechanismen**: Automatische Wiederholung bei temporären Fehlern
- **Graceful Degradation**: Kontinuierliche Funktion auch bei partiellen Ausfällen
+* **Redis Consumer Groups**: Skalierbare und ausfallsichere Event-Verarbeitung mit automatischer Last-Verteilung
+* **Pending Message Recovery**: Robuste Logik zum "Claimen" von Nachrichten ausgefallener Consumer
+* **Retry-Mechanismen**: Automatische Wiederholung bei temporären Fehlern
+* **Graceful Degradation**: Kontinuierliche Funktion auch bei partiellen Ausfällen

 ### 📊 Intelligente Serialisierung
- **Metadata Separation**: Event-Metadaten und Nutzlast werden getrennt gespeichert für effiziente Stream-Analyse
- **Type Registry**: Dynamische Event-Type-Registrierung für polymorphe Deserialisierung
- **JSON-basiert**: Verwendung von Jackson für robuste, schema-flexible Serialisierung
+* **Metadata Separation**: Event-Metadaten und Nutzlast werden getrennt gespeichert für effiziente Stream-Analyse
+* **Type Registry**: Dynamische Event-Type-Registrierung für polymorphe Deserialisierung
+* **JSON-basiert**: Verwendung von Jackson für robuste, schema-flexible Serialisierung

 ### 🚀 Performance-Optimierung
- **Stream-basierte Speicherung**: Optimale Performance durch Redis Streams
- **Optimierte Batch-Operationen**: Alle Events einer Batch werden in einer einzigen Redis-Transaktion verarbeitet (bis zu 90% Performance-Verbesserung)
- **Intelligente Version-Cache**: Thread-sicherer Cache mit Hit/Miss-Tracking für Stream-Versionen
- **Connection Pooling**: Konfigurierbare Verbindungspools für optimale Resource-Nutzung
- **Asynchrone Verarbeitung**: Non-blocking Event-Processing
+* **Stream-basierte Speicherung**: Optimale Performance durch Redis Streams
+* **Optimierte Batch-Operationen**: Alle Events einer Batch werden in einer einzigen Redis-Transaktion verarbeitet (bis zu 90% Performance-Verbesserung)
+* **Intelligente Version-Cache**: Thread-sicherer Cache mit Hit/Miss-Tracking für Stream-Versionen
+* **Connection Pooling**: Konfigurierbare Verbindungspools für optimale Resource-Nutzung
+* **Asynchrone Verarbeitung**: Non-blocking Event-Processing

 ### 📊 Enhanced Monitoring & Performance Tracking (NEW)
- **Real-time Metrics Collection**: Automatisches Tracking aller Event-Store-Operationen mit detaillierten Performance-Metriken
- **Comprehensive Operation Tracking**: Einzelne und Batch-Appends, Read-Operationen, Subscriptions mit Erfolgsraten
- **Cache Performance Monitoring**: Detaillierte Hit/Miss-Ratios für optimale Cache-Tuning
- **Concurrency Conflict Detection**: Spezifisches Tracking von Optimistic-Locking-Konflikten
- **Automated Performance Logging**: Periodische Performance-Reports alle 5 Minuten mit strukturierten Metriken
- **Event Throughput Analytics**: Tracking von Events/Sekunde für Capacity Planning
- **Error Rate Monitoring**: Detaillierte Fehlerklassifizierung und -tracking
+* **Real-time Metrics Collection**: Automatisches Tracking aller Event-Store-Operationen mit detaillierten Performance-Metriken
+* **Comprehensive Operation Tracking**: Einzelne und Batch-Appends, Read-Operationen, Subscriptions mit Erfolgsraten
+* **Cache Performance Monitoring**: Detaillierte Hit/Miss-Ratios für optimale Cache-Tuning
+* **Concurrency Conflict Detection**: Spezifisches Tracking von Optimistic-Locking-Konflikten
+* **Automated Performance Logging**: Periodische Performance-Reports alle 5 Minuten mit strukturierten Metriken
+* **Event Throughput Analytics**: Tracking von Events/Sekunde für Capacity Planning
+* **Error Rate Monitoring**: Detaillierte Fehlerklassifizierung und -tracking

 ## Konfiguration

@@ -449,19 +449,19 @@ fun `consumer should process events reliably`() {

 ### Test-Features

- **Testcontainers Integration**: Echte Redis-Instanz für Integrationstests
- **Deterministische Tests**: Manueller Polling-Trigger statt Thread.sleep
- **Saubere Test-Daten**: @Transient-Annotation für Event-Klassen
- **Umfassende Szenarien**: Configuration, Error Handling, Stream, Resilience Tests
+* **Testcontainers Integration**: Echte Redis-Instanz für Integrationstests
+* **Deterministische Tests**: Manueller Polling-Trigger statt Thread.sleep
+* **Saubere Test-Daten**: @Transient-Annotation für Event-Klassen
+* **Umfassende Szenarien**: Configuration, Error Handling, Stream, Resilience Tests

 ## Performance & Monitoring

 ### Performance-Charakteristiken

- **Durchsatz**: >10 000 Events/Sekunde bei optimaler Konfiguration
- **Latenz**: <10ms für Event-Appending, <50ms für Event-Reading
- **Skalierung**: Horizontal skalierbar durch Consumer Groups
- **Speicher**: Effiziente Stream-basierte Speicherung
+* **Durchsatz**: >10 000 Events/Sekunde bei optimaler Konfiguration
+* **Latenz**: <10ms für Event-Appending, <50ms für Event-Reading
+* **Skalierung**: Horizontal skalierbar durch Consumer Groups
+* **Speicher**: Effiziente Stream-basierte Speicherung

 ### Monitoring-Metriken

@@ -514,6 +514,7 @@ class EventStoreHealthIndicator(
 ### Häufige Probleme

 #### 1. ConcurrencyException
+
 ```kotlin
 // Problem: Race Condition bei parallel Schreibvorgängen
 // Lösung: Retry-Logic mit exponential backoff
@@ -524,6 +525,7 @@ fun appendWithRetry(event: DomainEvent, streamId: UUID, expectedVersion: Long) {
 ```

 #### 2. Consumer Lag
+
 ```bash
 # Redis CLI - Check consumer group info
 XINFO GROUPS event-stream:aggregate-id
@@ -536,6 +538,7 @@ XCLAIM event-stream:aggregate-id event-processors consumer-name 60000 message-id
 ```

 #### 3. Speicher-Issues
+
 ```yaml
 # Redis Memory Optimization
 redis:
@@ -548,6 +551,7 @@ redis:
 ```

 #### 4. Verbindungsprobleme
+
 ```yaml
 # Connection troubleshooting
 redis:
@@ -584,12 +588,12 @@ redis-cli INFO memory

 ### Deployment Checklist

- [ ] Redis Cluster verfügbar und erreichbar
- [ ] Konfiguration für Umgebung angepasst
- [ ] Consumer Groups erstellt (automatisch oder manuell)
- [ ] Monitoring und Alerting konfiguriert
- [ ] Health Checks implementiert
- [ ] Backup-Strategie definiert
+* [ ] Redis Cluster verfügbar und erreichbar
+* [ ] Konfiguration für Umgebung angepasst
+* [ ] Consumer Groups erstellt (automatisch oder manuell)
+* [ ] Monitoring und Alerting konfiguriert
+* [ ] Health Checks implementiert
+* [ ] Backup-Strategie definiert

 ### Migration zwischen Versionen

@@ -7,6 +7,7 @@ Dieses Modul stellt eine konkrete Implementierung der `event-store-api` unter Ve
 ## Architektur

 Das Modul folgt dem Provider-Pattern:
+
 - **event-store-api**: Provider-agnostische Interfaces (`EventStore`, `EventSerializer`)
 - **redis-event-store**: Redis Streams-spezifische Implementierung

@@ -150,6 +151,7 @@ Die Module verwenden unterschiedliche Bean-Namen zur Vermeidung von Konflikten:
 ### Keine Konflikte

 ✅ Die Module sind so designed, dass sie **ohne Konflikte** gleichzeitig verwendet werden können:
+
 - **Separate ConnectionFactories** mit `@Qualifier` Annotations
 - **Separate Property-Prefixes**: `redis` vs `redis.event-store`
 - **Unterschiedliche Database-Nummern**: 0 vs 1
@@ -219,6 +221,7 @@ val eventsFromVersion = eventStore.loadEvents(
 ## Serialisierung

 Das Modul verwendet Jackson für Event-Serialisierung:
+
 - Automatische Kotlin-Modul Integration
 - Polymorphe Serialisierung für verschiedene Event-Typen
 - Custom Serializer können via `@Bean` überschrieben werden
@@ -274,4 +277,4 @@ Wenn Sie Fehler wie "Multiple beans of type RedisConnectionFactory" erhalten:

 - Siehe auch: [cache-api README](../../cache/cache-api/README.md)
 - Siehe auch: [redis-cache README](../../cache/redis-cache/README.md)
- Redis Streams Dokumentation: https://redis.io/docs/data-types/streams/
+- Redis Streams Dokumentation: <https://redis.io/docs/data-types/streams/>
@@ -20,22 +20,26 @@ Dieses Dokument beschreibt alle zentralen Konfigurationseigenschaften für das A
 ## Server Configuration

 ### server.port
+
 - **Typ**: Integer
 - **Default**: 8081
 - **Environment Variable**: `GATEWAY_PORT`
 - **Beschreibung**: Port, auf dem das Gateway läuft

 ### server.netty.connection-timeout
+
 - **Typ**: Duration
 - **Default**: 5s
 - **Beschreibung**: Timeout für initiale TCP-Verbindungen

 ### server.netty.idle-timeout
+
 - **Typ**: Duration
 - **Default**: 15s
 - **Beschreibung**: Timeout für inaktive Verbindungen

 **Beispiel:**
+
 ```yaml
 server:
  port: 8081
@@ -49,11 +53,13 @@ server:
 ## Spring Application

 ### spring.application.name
+
 - **Typ**: String
 - **Default**: api-gateway
 - **Beschreibung**: Name der Anwendung, wird in Consul und Logs verwendet

 ### spring.profiles.active
+
 - **Typ**: String
 - **Default**: dev
 - **Environment Variable**: `SPRING_PROFILES_ACTIVE`
@@ -61,6 +67,7 @@ server:
 - **Mögliche Werte**: dev, test, staging, prod

 ### spring.security.user.name / password
+
 - **Typ**: String
 - **Default**: admin / admin
 - **Environment Variables**: `GATEWAY_ADMIN_USER`, `GATEWAY_ADMIN_PASSWORD`
@@ -68,6 +75,7 @@ server:
 - **⚠️ Wichtig**: In Produktion durch sichere Werte ersetzen!

 **Beispiel:**
+
 ```yaml
 spring:
  application:
@@ -85,51 +93,60 @@ spring:
 ## Consul Service Discovery

 ### spring.cloud.consul.host
+
 - **Typ**: String
 - **Default**: localhost
 - **Environment Variable**: `CONSUL_HOST`
 - **Beschreibung**: Hostname des Consul-Servers

 ### spring.cloud.consul.port
+
 - **Typ**: Integer
 - **Default**: 8500
 - **Environment Variable**: `CONSUL_PORT`
 - **Beschreibung**: Port des Consul-Servers

 ### spring.cloud.consul.enabled
+
 - **Typ**: Boolean
 - **Default**: true
 - **Environment Variable**: `CONSUL_ENABLED`
 - **Beschreibung**: Aktiviert/Deaktiviert Consul Integration

 ### spring.cloud.consul.discovery.enabled
+
 - **Typ**: Boolean
 - **Default**: true
 - **Environment Variable**: `CONSUL_ENABLED`
 - **Beschreibung**: Aktiviert Service Discovery

 ### spring.cloud.consul.discovery.register
+
 - **Typ**: Boolean
 - **Default**: true
 - **Environment Variable**: `CONSUL_ENABLED`
 - **Beschreibung**: Registriert das Gateway in Consul

 ### spring.cloud.consul.discovery.health-check-path
+
 - **Typ**: String
 - **Default**: /actuator/health
 - **Beschreibung**: Pfad für Consul Health Checks

 ### spring.cloud.consul.discovery.health-check-interval
+
 - **Typ**: Duration
 - **Default**: 10s
 - **Beschreibung**: Intervall für Health Checks

 ### spring.cloud.consul.discovery.instance-id
+
 - **Typ**: String
 - **Default**: ${spring.application.name}-${server.port}-${random.uuid}
 - **Beschreibung**: Eindeutige Instanz-ID für Service Discovery

 **Beispiel:**
+
 ```yaml
 spring:
  cloud:
@@ -152,26 +169,31 @@ spring:
 ### Verbindungskonfiguration

 #### spring.cloud.gateway.server.webflux.httpclient.connect-timeout
+
 - **Typ**: Integer (Millisekunden)
 - **Default**: 5000
 - **Beschreibung**: Timeout für Backend-Verbindungen

 #### spring.cloud.gateway.server.webflux.httpclient.response-timeout
+
 - **Typ**: Duration
 - **Default**: 30s
 - **Beschreibung**: Timeout für Backend-Responses

 #### spring.cloud.gateway.server.webflux.httpclient.pool.max-idle-time
+
 - **Typ**: Duration
 - **Default**: 15s
 - **Beschreibung**: Max. Idle-Zeit für Verbindungen im Pool

 #### spring.cloud.gateway.server.webflux.httpclient.pool.max-life-time
+
 - **Typ**: Duration
 - **Default**: 60s
 - **Beschreibung**: Max. Lebensdauer einer Verbindung

 **Beispiel:**
+
 ```yaml
 spring:
  cloud:
@@ -197,6 +219,7 @@ Diese Filter werden auf **alle** Routen angewendet:
 5. **Cache-Control**: No-cache Header für alle Responses

 **Beispiel:**
+
 ```yaml
 spring:
  cloud:
@@ -223,41 +246,48 @@ spring:
 Das Gateway definiert folgende Service-Routen:

 #### 1. Members Service Route
+
 - **Path**: `/api/members/**`
 - **Service**: members-service (via Consul)
 - **Circuit Breaker**: membersCircuitBreaker
 - **Fallback**: /fallback/members

 #### 2. Horses Service Route
+
 - **Path**: `/api/horses/**`
 - **Service**: horses-service (via Consul)
 - **Circuit Breaker**: horsesCircuitBreaker
 - **Fallback**: /fallback/horses

 #### 3. Events Service Route
+
 - **Path**: `/api/events/**`
 - **Service**: events-service (via Consul)
 - **Circuit Breaker**: eventsCircuitBreaker
 - **Fallback**: /fallback/events

 #### 4. Masterdata Service Route
+
 - **Path**: `/api/masterdata/**`
 - **Service**: masterdata-service (via Consul)
 - **Circuit Breaker**: masterdataCircuitBreaker
 - **Fallback**: /fallback/masterdata

 #### 5. Auth Service Route
+
 - **Path**: `/api/auth/**`
 - **Service**: auth-service (via Consul)
 - **Circuit Breaker**: authCircuitBreaker
 - **Fallback**: /fallback/auth

 #### 6. Ping Service Route
+
 - **Path**: `/api/ping/**`
 - **Service**: ping-service (via Consul)
 - **No Circuit Breaker**: Optional service

 **Beispiel einer Route:**
+
 ```yaml
 spring:
  cloud:
@@ -282,31 +312,37 @@ spring:
 ### Default Konfiguration

 #### resilience4j.circuitbreaker.configs.default.registerHealthIndicator
+
 - **Typ**: Boolean
 - **Default**: true
 - **Beschreibung**: Registriert Circuit Breaker im Health Endpoint

 #### resilience4j.circuitbreaker.configs.default.slidingWindowSize
+
 - **Typ**: Integer
 - **Default**: 100
 - **Beschreibung**: Größe des Sliding Window für Fehlerrate-Berechnung

 #### resilience4j.circuitbreaker.configs.default.minimumNumberOfCalls
+
 - **Typ**: Integer
 - **Default**: 20
 - **Beschreibung**: Mindestanzahl an Calls bevor Circuit Breaker aktiviert wird

 #### resilience4j.circuitbreaker.configs.default.permittedNumberOfCallsInHalfOpenState
+
 - **Typ**: Integer
 - **Default**: 3
 - **Beschreibung**: Anzahl Test-Calls im Half-Open State

 #### resilience4j.circuitbreaker.configs.default.waitDurationInOpenState
+
 - **Typ**: Duration
 - **Default**: 5s
 - **Beschreibung**: Wartezeit bevor von Open zu Half-Open gewechselt wird

 #### resilience4j.circuitbreaker.configs.default.failureRateThreshold
+
 - **Typ**: Integer (Prozent)
 - **Default**: 50
 - **Beschreibung**: Fehlerrate-Schwelle für Circuit Breaker Aktivierung
@@ -324,6 +360,7 @@ Jeder Service hat einen eigenen Circuit Breaker mit angepasster Konfiguration:
 | auth-service | 20 | 30% | Sensitiverer Threshold |

 **Beispiel:**
+
 ```yaml
 resilience4j:
  circuitbreaker:
@@ -341,11 +378,13 @@ resilience4j:
 ### Exposed Endpoints

 #### management.endpoints.web.exposure.include
+
 - **Typ**: Comma-separated String
 - **Default**: health,info,metrics,prometheus,gateway,circuitbreakers
 - **Beschreibung**: Öffentlich verfügbare Actuator Endpoints

 **Verfügbare Endpoints:**
+
 - `/actuator/health` - Service Health Status
 - `/actuator/info` - Service Informationen
 - `/actuator/metrics` - Micrometer Metriken
@@ -356,17 +395,20 @@ resilience4j:
 ### Health Endpoint

 #### management.endpoint.health.show-details
+
 - **Typ**: String
 - **Default**: always
 - **Mögliche Werte**: never, when-authorized, always
 - **Beschreibung**: Zeigt detaillierte Health-Informationen

 #### management.endpoint.health.show-components
+
 - **Typ**: Boolean
 - **Default**: always
 - **Beschreibung**: Zeigt Health-Komponenten

 #### management.endpoint.health.probes.enabled
+
 - **Typ**: Boolean
 - **Default**: true
 - **Beschreibung**: Aktiviert Kubernetes Liveness/Readiness Probes
@@ -374,6 +416,7 @@ resilience4j:
 ### Metrics

 #### management.metrics.tags
+
 - **Beschreibung**: Globale Tags für alle Metriken
 - **Standard Tags**:
  - application: ${spring.application.name}
@@ -384,11 +427,13 @@ resilience4j:
  - gateway: api-gateway

 #### management.metrics.distribution.percentiles-histogram.http.server.requests
+
 - **Typ**: Boolean
 - **Default**: true
 - **Beschreibung**: Aktiviert Histogram für Request-Zeiten

 #### management.metrics.distribution.percentiles.http.server.requests
+
 - **Typ**: Array[Double]
 - **Default**: [0.5, 0.90, 0.95, 0.99]
 - **Beschreibung**: Percentile-Werte für Request-Zeiten
@@ -396,24 +441,28 @@ resilience4j:
 ### Tracing

 #### management.tracing.enabled
+
 - **Typ**: Boolean
 - **Default**: false
 - **Environment Variable**: `TRACING_ENABLED`
 - **Beschreibung**: Aktiviert Distributed Tracing

 #### management.tracing.sampling.probability
+
 - **Typ**: Double (0.0 - 1.0)
 - **Default**: 1.0
 - **Environment Variable**: `TRACING_SAMPLING_PROBABILITY`
 - **Beschreibung**: Sampling-Rate für Traces (1.0 = 100%)

 #### management.zipkin.tracing.endpoint
+
 - **Typ**: URL
- **Default**: http://localhost:9411/api/v2/spans
+- **Default**: <http://localhost:9411/api/v2/spans>
 - **Environment Variable**: `ZIPKIN_TRACING_ENDPOINT`
 - **Beschreibung**: Zipkin Server URL

 **Beispiel:**
+
 ```yaml
 management:
  endpoints:
@@ -441,41 +490,49 @@ management:
 Die Security-Konfiguration erfolgt über Custom Properties unter `gateway.security`:

 ### gateway.security.publicPaths
+
 - **Typ**: Array[String]
 - **Default**: ["/", "/fallback/**", "/actuator/**", "/webjars/**", "/v3/api-docs/**", "/api/auth/**"]
 - **Beschreibung**: Pfade, die ohne Authentifizierung zugänglich sind

 ### gateway.security.cors.allowedOriginPatterns
+
 - **Typ**: Array[String]
 - **Default**: ["http://localhost:[*]", "https://*.meldestelle.at"]
 - **Beschreibung**: Erlaubte Origin-Patterns für CORS

 ### gateway.security.cors.allowedMethods
+
 - **Typ**: Array[String]
 - **Default**: ["GET", "POST", "PUT", "DELETE", "OPTIONS", "PATCH"]
 - **Beschreibung**: Erlaubte HTTP-Methoden

 ### gateway.security.cors.allowedHeaders
+
 - **Typ**: Array[String]
 - **Default**: ["*"]
 - **Beschreibung**: Erlaubte Request-Headers

 ### gateway.security.cors.exposedHeaders
+
 - **Typ**: Array[String]
 - **Default**: ["X-Correlation-ID", "X-RateLimit-Limit", "X-RateLimit-Remaining"]
 - **Beschreibung**: Headers die an Client exponiert werden

 ### gateway.security.cors.allowCredentials
+
 - **Typ**: Boolean
 - **Default**: true
 - **Beschreibung**: Erlaubt Credentials (Cookies, Auth-Header)

 ### gateway.security.cors.maxAge
+
 - **Typ**: Duration
 - **Default**: 1h
 - **Beschreibung**: Cache-Zeit für CORS Preflight-Requests

 **Beispiel:**
+
 ```yaml
 gateway:
  security:
@@ -499,19 +556,22 @@ gateway:
 ### JWT Configuration

 #### spring.security.oauth2.resourceserver.jwt.jwk-set-uri
+
 - **Typ**: URL
 - **Environment Variable**: `KEYCLOAK_JWK_SET_URI`
 - **Beschreibung**: Keycloak JWK Set URI für JWT-Validierung
- **Beispiel**: http://localhost:8180/realms/meldestelle/protocol/openid-connect/certs
+- **Beispiel**: <http://localhost:8180/realms/meldestelle/protocol/openid-connect/certs>

 ---

 ## Logging

 ### logging.level
+
 - **Beschreibung**: Log-Level für verschiedene Pakete

 **Standard Log-Levels:**
+
 - `org.springframework.cloud.gateway`: INFO
 - `org.springframework.cloud.loadbalancer`: DEBUG
 - `org.springframework.cloud.consul`: INFO
@@ -522,23 +582,28 @@ gateway:
 - `org.springframework.web`: INFO

 ### logging.pattern.console
+
 - **Beschreibung**: Console-Log-Pattern mit Farben und Correlation-ID

 ### logging.pattern.file
+
 - **Beschreibung**: File-Log-Pattern ohne Farben

 ### logging.file.name
+
 - **Typ**: String
 - **Default**: infrastructure/gateway/logs/gateway.log
 - **Beschreibung**: Log-Datei Pfad

 ### logging.logback.rollingpolicy
+
 - **clean-history-on-start**: true
 - **max-file-size**: 100MB
 - **total-size-cap**: 1GB
 - **max-history**: 30 (Tage)

 **Beispiel:**
+
 ```yaml
 logging:
  level:
@@ -566,9 +631,9 @@ logging:
 | `CONSUL_ENABLED` | Consul Aktivieren | true |
 | `GATEWAY_ADMIN_USER` | Admin Username | admin |
 | `GATEWAY_ADMIN_PASSWORD` | Admin Password | admin |
-| `KEYCLOAK_JWK_SET_URI` | Keycloak JWK URI | http://localhost:8180/... |
+| `KEYCLOAK_JWK_SET_URI` | Keycloak JWK URI | <http://localhost:8180/>... |
 | `TRACING_ENABLED` | Tracing aktivieren | false |
-| `ZIPKIN_TRACING_ENDPOINT` | Zipkin Server | http://localhost:9411/... |
+| `ZIPKIN_TRACING_ENDPOINT` | Zipkin Server | <http://localhost:9411/>... |
 | `SPRING_PROFILES_ACTIVE` | Spring Profil | dev |

 ---
@@ -578,22 +643,26 @@ logging:
 Das Gateway unterstützt verschiedene Spring Profile:

 ### dev (Development)
+
 - Detailliertes Logging
 - Alle Monitoring-Endpunkte verfügbar
 - Tracing optional

 ### test
+
 - Reduziertes Logging
 - Test-spezifische Timeouts
 - In-Memory Services optional

 ### prod (Production)
+
 - Production-ready Logging
 - Sichere Credentials erforderlich
 - Tracing empfohlen
 - Rate Limiting aktiviert

 **Beispiel für profile-spezifische Datei:**
+
 ```yaml
 # application-prod.yml
 spring:
@@ -631,21 +700,25 @@ logging:
 ## Troubleshooting

 ### Gateway startet nicht
+
 - ✅ Prüfen: Consul erreichbar?
 - ✅ Prüfen: Port 8081 frei?
 - ✅ Prüfen: Keycloak erreichbar? (Optional)

 ### Service nicht erreichbar
+
 - ✅ Prüfen: Service in Consul registriert?
 - ✅ Prüfen: Circuit Breaker offen?
 - ✅ Prüfen: Health Check erfolgreich?

 ### CORS-Fehler
+
 - ✅ Prüfen: Origin in allowedOriginPatterns?
 - ✅ Prüfen: Methode in allowedMethods?
 - ✅ Prüfen: allowCredentials korrekt?

 ### Hohe Latenz
+
 - ✅ Prüfen: response-timeout zu hoch?
 - ✅ Prüfen: Backend-Services langsam?
 - ✅ Prüfen: Connection Pool ausgeschöpft?
@@ -11,6 +11,7 @@ Das API-Gateway ist der zentrale und einzige öffentliche Einstiegspunkt für al
 Das Gateway ist als eigenständiger Spring Boot Service implementiert und nutzt Spring Cloud Gateway als technologische Grundlage. Spring Cloud Gateway ist ein reaktives, nicht-blockierendes Framework, das sich nahtlos in das Spring-Ökosystem integriert.

 ### Technologie-Stack
+
 - **Spring Boot 3.x** - Moderne Spring Boot Anwendung
 - **Spring Cloud Gateway** - Reaktives Gateway Framework
 - **Spring WebFlux** - Reaktive Web-Programmierung mit Netty
@@ -25,11 +26,13 @@ Das Gateway ist als eigenständiger Spring Boot Service implementiert und nutzt
 Das Gateway handhabt alle Cross-Cutting Concerns (übergreifende Belange), die für mehrere oder alle Microservices gelten und entlastet damit die Fach-Services von technischen Aufgaben.

 ### 1. Dynamisches Routing
+
 - **Service Discovery Integration**: Vollständige Consul Integration für automatische Service-Erkennung
 - **Load Balancing**: Intelligente Lastverteilung zwischen Service-Instanzen
 - **Health-basiertes Routing**: Weiterleitung nur an gesunde Service-Instanzen

 **Verfügbare Routen**:
+
 - `/api/members/**` → members-service
 - `/api/horses/**` → horses-service
 - `/api/events/**` → events-service
@@ -38,12 +41,14 @@ Das Gateway handhabt alle Cross-Cutting Concerns (übergreifende Belange), die f
 - `/api/ping/**` → ping-service

 ### 2. Sicherheit und Authentifizierung
+
 - **JWT Security Enforcement**: Validierung von Bearer Tokens für alle geschützten Endpunkte
 - **Public Path Exemptions**: Konfigurierbare öffentliche Pfade (`/`, `/health`, `/actuator/**`, `/api/auth/login`)
 - **User Context Injection**: Automatische Weiterleitung von User-ID und Rolle an Backend Services
 - **Standardisierte Fehlerbehandlung**: Strukturierte 401 Unauthorized Responses

 ### 3. Rate Limiting
+
 - **Intelligentes Rate Limiting** basierend auf User-Typ:
  - **Anonymous Users**: 50 Anfragen pro Minute
  - **Authenticated Users**: 200 Anfragen pro Minute
@@ -52,15 +57,18 @@ Das Gateway handhabt alle Cross-Cutting Concerns (übergreifende Belange), die f
 - **Custom Headers**: X-RateLimit-* Header für Client-Information

 ### 4. Circuit Breaker und Resilienz
+
 - **Service-spezifische Circuit Breaker**: Resilience4j Integration für jeden Backend Service
 - **Fallback Mechanismen**: Benutzerfreundliche Fehlermeldungen bei Service-Ausfällen
 - **Retry Logic**: Automatische Wiederholungen bei transienten Fehlern
 - **Graceful Degradation**: Systembetrieb auch bei partiellen Service-Ausfällen

 ### 5. Monitoring und Observability
+
 Das Gateway implementiert umfassende Observability durch eine vollständig integrierte Micrometer-basierte Metriken-Architektur.

 #### Automatische Metriken-Erfassung (GatewayMetricsConfig)
+
 - **Request Duration Tracking**: Automatische Messung aller Request-Response Zyklen
  - Metric: `gateway_request_duration` (Timer)
  - Tags: method, path, status, status_series
@@ -77,12 +85,14 @@ Das Gateway implementiert umfassende Observability durch eine vollständig integ
  - Integration mit Resilience4j Circuit Breaker Status

 #### Intelligente Pfad-Normalisierung
+
 - **Kardinalitäts-Kontrolle**: Automatische Normalisierung von dynamischen Pfaden
  - `/api/horses/123` → `/api/horses/{id}`
  - UUID-Pattern → `/{uuid}`
  - Sehr lange Pfade werden gekürzt (100+ Zeichen)

 #### Health Monitoring Integration
+
 - **Downstream Service Health**: Umfassende Überwachung aller Backend Services
  - Kritische Services: Members, Horses, Events, Masterdata, Auth
  - Optionale Services: Ping Service
@@ -91,11 +101,13 @@ Das Gateway implementiert umfassende Observability durch eine vollständig integ
 - **Strukturierte Logs**: JSON-Format für maschinelle Auswertung

 #### Prometheus Export
+
 - **Automatischer Export**: Alle Metriken werden automatisch an Prometheus exportiert
 - **Common Tags**: Alle Metriken erhalten automatisch Service- und Component-Tags
 - **Filter-Optimierung**: Rauschen-reduzierende Metrik-Filter für interne Spring/Netty Metriken

 ### 6. CORS-Management
+
 - **Produktionstaugliche CORS-Konfiguration**:
  - Erlaubte Origins: `https://*.meldestelle.at`, `http://localhost:*`
  - Alle HTTP-Methoden (GET, POST, PUT, DELETE, PATCH, OPTIONS)
@@ -104,6 +116,7 @@ Das Gateway implementiert umfassende Observability durch eine vollständig integ
 ## Implementierte Optimierungen

 ### Gateway-Konfiguration (application.yml)
+
 ✅ **Vollständige Service-Routen**: Routing für alle Business Services
 ✅ **Circuit Breaker Integration**: Service-spezifische Resilience4j Konfigurationen
 ✅ **Connection Pooling**: Optimierte HTTP-Client-Konfiguration
@@ -111,24 +124,28 @@ Das Gateway implementiert umfassende Observability durch eine vollständig integ
 ✅ **Enhanced Logging**: Strukturierte Logs mit Korrelations-IDs und Performance-Daten

 ### Health Monitoring (GatewayHealthIndicator.kt)
+
 ✅ **Downstream Service Monitoring**: Überwachung aller kritischen Services
 ✅ **Service Discovery Integration**: Consul-basierte Service-Erkennung
 ✅ **Test-Environment Handling**: Graceful Degradation in Test-Umgebungen
 ✅ **Detailliertes Error Reporting**: Umfassende Statusinformationen

 ### Build-Optimierungen (build.gradle.kts)
+
 ✅ **SINGLE SOURCE OF TRUTH**: Alle Dependencies über libs.versions.toml
 ✅ **Build Info Generation**: Automatische Build-Metadaten
 ✅ **Modern Kotlin Compiler**: Optimierte Compiler-Einstellungen
 ✅ **Dependency Optimization**: Bereinigung redundanter Dependencies

 ### Docker-Optimierungen (Dockerfile)
+
 ✅ **Multi-Stage Build**: Spring Boot Layer-Extraktion für 90%+ besseres Caching
 ✅ **Security Hardening**: Non-root User, Security Updates
 ✅ **OCI Compliance**: Vollständige Container-Metadaten
 ✅ **Production-Ready**: Optimierte JVM-Settings für Container-Umgebung

 ### Metriken-Integration (GatewayMetricsConfig.kt)
+
 ✅ **Comprehensive Micrometer Integration**: Vollständige Metriken-Erfassung mit automatischem Prometheus Export
 ✅ **Request/Response Time Tracking**: Detaillierte Performance-Metriken mit Percentile-Auswertung
 ✅ **Error Rate Monitoring**: Intelligente Fehler-Klassifikation und -Tracking
@@ -137,6 +154,7 @@ Das Gateway implementiert umfassende Observability durch eine vollständig integ
 ✅ **Custom Business Metrics**: Erweiterbare Metrik-Architektur für fachliche KPIs

 ### Dokumentation
+
 ✅ **OpenAPI 3.0.3 Spezifikation**: Vollständige API-Dokumentation mit Members Service
 ✅ **Interactive Swagger UI**: Modern dokumentierte API-Endpunkte
 ✅ **Static HTML Documentation**: Responsive, moderne Dokumentations-Website
@@ -145,16 +163,19 @@ Das Gateway implementiert umfassende Observability durch eine vollständig integ
 ## Performance und Reliability

 ### Netty Server Optimierungen
+
 - **Connection Timeouts**: 5 Sekunden für optimale Responsiveness
 - **Idle Timeout**: 15 Sekunden für effiziente Resource-Nutzung
 - **Elastic Connection Pool**: Automatische Skalierung basierend auf Load

 ### Circuit Breaker Konfiguration
+
 - **Sliding Window**: 100 Anfragen für Default, service-spezifische Anpassungen
 - **Failure Rate Threshold**: 50% für Standard-Services, 30% für Auth-Service
 - **Half-Open State**: 3 Test-Anfragen für Service-Recovery

 ### JVM Optimierungen (Container)
+
 ```bash
 JAVA_OPTS="-server -Xmx512m -Xms256m -XX:+UseG1GC
           -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0"
@@ -181,6 +202,7 @@ Ein typischer Anfrage-Flow:
 ## Monitoring und Health Checks

 ### Actuator Endpunkte
+
 - `/actuator/health` - Umfassender Health Status aller Services
 - `/actuator/metrics` - Prometheus-kompatible Metriken
 - `/actuator/info` - Anwendungs- und Build-Informationen
@@ -190,6 +212,7 @@ Ein typischer Anfrage-Flow:
 ### Key Performance Indicators (KPIs)

 #### Automatisch erfasste Metriken
+
 - **Request Throughput**: `gateway_requests_total` - Anfragen pro Sekunde nach Method/Path
 - **Response Times**: `gateway_request_duration` - P50, P90, P95, P99 Percentile nach Status
 - **Error Rates**: `gateway_errors_total` - 4xx/5xx Response Codes mit Error-Type Klassifikation
@@ -197,6 +220,7 @@ Ein typischer Anfrage-Flow:
 - **Service Availability**: Upstream Service Health via Health Indicators

 #### Verfügbare Metric Tags für detaillierte Analyse
+
 - **method**: HTTP-Method (GET, POST, PUT, DELETE, etc.)
 - **path**: Normalisierter API-Pfad (z.B. `/api/horses/{id}`)
 - **status**: HTTP-Status-Code (200, 404, 500, etc.)
@@ -206,6 +230,7 @@ Ein typischer Anfrage-Flow:
 - **component**: Automatisches "infrastructure" Tag

 #### Prometheus Query Beispiele
+
 ```promql
 # Request Rate pro Endpunkt
 rate(gateway_requests_total[5m])
@@ -223,12 +248,14 @@ increase(gateway_circuit_breaker_events_total[1h])
 ## Security Features

 ### JWT Authentication
+
 - **Bearer Token Validation**: Automatische JWT-Verifikation
 - **Role Extraction**: User-Rolle für Backend Services verfügbar
 - **Token Refresh**: Unterstützung für Token-Erneuerung
 - **Public Endpoints**: Konfigurierbare Ausnahmen für öffentliche APIs

 ### Security Headers
+
 ```yaml
 X-Content-Type-Options: nosniff
 X-Frame-Options: DENY
@@ -258,6 +285,7 @@ docker run -p 8080:8080 meldestelle/gateway:latest
 📖 **Detaillierte Startup-Anleitung:** Siehe `GATEWAY-STARTUP-GUIDE.md` im Projekt-Root für vollständige Befehle und Fehlerbehebung.

 ### Testing
+
 ```bash
 # Unit Tests
 ./gradlew :infrastructure:gateway:test
@@ -269,6 +297,7 @@ docker run -p 8080:8080 meldestelle/gateway:latest
 ## Konfiguration

 ### Environment Variables
+
 ```bash
 SPRING_PROFILES_ACTIVE=prod
 CONSUL_HOST=consul.meldestelle.at
@@ -278,6 +307,7 @@ GATEWAY_ADMIN_PASSWORD=secure-password
 ```

 ### Profile-spezifische Konfiguration
+
 - **dev**: Entwicklungsumgebung mit Debug-Logging
 - **test**: Test-Umgebung mit Mock Services
 - **prod**: Produktionsumgebung mit allen Security Features
@@ -285,6 +315,7 @@ GATEWAY_ADMIN_PASSWORD=secure-password
 ## Deployment

 ### Docker Deployment
+
 ```bash
 # Multi-stage Build mit Layer Caching
 docker build -t meldestelle/gateway:1.0.0 \
@@ -300,6 +331,7 @@ docker run -d \
 ```

 ### Kubernetes Deployment
+
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -330,21 +362,25 @@ spec:
 ### Häufige Probleme

 **Service Discovery Issues**
+
 - Consul Connectivity prüfen
 - Service Registration Status überprüfen
 - DNS Resolution testen

 **Circuit Breaker Activation**
+
 - Service Health Status prüfen
 - Failure Rate Threshold analysieren
 - Manual Circuit Breaker Reset über Actuator

 **Performance Issues**
+
 - Connection Pool Metrics analysieren
 - JVM Heap Usage monitoring
 - Request Rate Limiting überprüfen

 **Metriken und Monitoring Issues**
+
 - Prometheus Scraping Endpunkt prüfen: `/actuator/prometheus`
 - Metrics Registry Status überprüfen: `/actuator/metrics`
 - GatewayMetricsWebFilter Aktivierung validieren
@@ -352,6 +388,7 @@ spec:
 - Path Normalization bei unerwarteten Metric-Namen

 ### Logging und Debugging
+
 ```bash
 # Logs mit Korrelations-IDs
 docker logs gateway | grep "correlationId"
@@ -366,12 +403,14 @@ curl http://localhost:8080/actuator/health
 ## Zukünftige Erweiterungen

 ### Geplante Features
+
 - **OAuth2/OIDC Integration**: Erweiterte Authentifizierung
 - **GraphQL Gateway**: Unified GraphQL Interface
 - **Caching Layer**: Redis-basiertes Response Caching
 - **Request/Response Transformation**: Dynamic Content Modification

 ### Performance Optimierungen
+
 - **HTTP/2 Support**: Moderne Protocol-Unterstützung
 - **Connection Pooling Tuning**: Erweiterte Pool-Konfiguration
 - **Reactive Streams Optimization**: Backpressure Handling
@@ -379,11 +418,13 @@ curl http://localhost:8080/actuator/health
 ## Dokumentation und Ressourcen

 ### API Dokumentation
+
 - **Swagger UI**: `/swagger` - Interactive API Documentation
 - **OpenAPI Spec**: `/openapi` - Machine-readable API Specification
 - **Static Documentation**: `/docs` - Comprehensive Documentation Hub

 ### Monitoring Dashboards
+
 - **Health Status**: `/actuator/health` - Real-time Service Health
 - **Metrics**: `/actuator/metrics` - Prometheus Metrics
 - **Gateway Routes**: `/actuator/gateway/routes` - Active Route Information
@@ -59,6 +59,8 @@ servers:
    description: Local Development Server

 tags:
+  - name: System
+    description: System information and health check endpoints
  - name: Authentication
    description: User authentication, registration, and profile management
  - name: Members
@@ -73,6 +75,8 @@ tags:
 paths:
  /:
    get:
+      tags:
+        - System
      summary: API Gateway Information
      description: Returns basic information about the API Gateway
      operationId: getApiGatewayInfo
@@ -86,6 +90,8 @@ paths:

  /health:
    get:
+      tags:
+        - System
      summary: Health Check
      description: Returns the health status of all bounded contexts
      operationId: getHealthStatus
@@ -99,6 +105,8 @@ paths:

  /api:
    get:
+      tags:
+        - System
      summary: API Documentation
      description: Returns information about available API endpoints
      operationId: getApiDocumentation
@@ -1509,7 +1517,7 @@ components:
        phone:
          type: string
          pattern: '^\+?[1-9]\d{1,14}$'
-          example: +43 123 456789
+          example: "+43123456789"
        dateOfBirth:
          type: string
          format: date
@@ -1543,7 +1551,7 @@ components:
        phone:
          type: string
          pattern: '^\+?[1-9]\d{1,14}$'
-          example: +43 123 456789
+          example: "+43123456789"
        address:
          $ref: '#/components/schemas/Address'
        membershipType:
@@ -1629,7 +1637,7 @@ components:
          example: Wien
        postalCode:
          type: string
-          example: 1010
+          example: "1010"
        state:
          type: string
          example: Wien
@@ -1844,7 +1852,7 @@ components:
          example: AT-LIP-2015-123
        chipNumber:
          type: string
-          example: 040123456789012
+          example: "040123456789012"
        passportNumber:
          type: string
          example: AT-P-2015-123
@@ -20,59 +20,57 @@ Das Modul implementiert moderne **Domain-Driven Design (DDD)** Prinzipien mit ex

 Das Modul ist in zwei spezialisierte Komponenten aufgeteilt, um Konfiguration von der Client-Logik zu trennen:

-
 infrastructure/messaging/
 ├── messaging-config/   # Stellt die zentrale Kafka-Konfiguration bereit
 └── messaging-client/   # Stellt wiederverwendbare, reaktive Clients bereit

-
 ### `messaging-config`

 Dieses Modul zentralisiert die grundlegende Kafka-Konfiguration für das gesamte Projekt.

-* **Zweck:** Definiert Spring-Beans für die `ProducerFactory` (Basis für Producer) und eine `Map` mit Standard-Konfigurationen für Consumer (z.B. `bootstrap-servers`, `group-id`, Serializer).
-* **Vorteil:** Stellt Konsistenz sicher und vereinfacht die Einrichtung neuer Producer oder Consumer in den Services.
+- **Zweck:** Definiert Spring-Beans für die `ProducerFactory` (Basis für Producer) und eine `Map` mit Standard-Konfigurationen für Consumer (z.B. `bootstrap-servers`, `group-id`, Serializer).
+- **Vorteil:** Stellt Konsistenz sicher und vereinfacht die Einrichtung neuer Producer oder Consumer in den Services.

 ### `messaging-client`

 Dieses Modul baut auf der Konfiguration auf und stellt wiederverwendbare High-Level-Komponenten für die Interaktion mit Kafka bereit.

-#### Kern-Komponenten:
+#### Kern-Komponenten

-* **`EventPublisher` Interface**: Definiert moderne APIs für das Publizieren von Domain Events
-    * **Moderne APIs**: `publishEvent()` und `publishEvents()` mit Result Pattern
-    * **Legacy APIs**: `publishEventReactive()` und `publishEventsReactive()` (deprecated)
+- **`EventPublisher` Interface**: Definiert moderne APIs für das Publizieren von Domain Events
+  - **Moderne APIs**: `publishEvent()` und `publishEvents()` mit Result Pattern
+  - **Legacy APIs**: `publishEventReactive()` und `publishEventsReactive()` (deprecated)

-* **`EventConsumer` Interface**: Definiert APIs für das Empfangen von Domain Events
-    * **Moderne APIs**: `receiveEventsWithResult()` mit Flow<Result<T>> für typsichere Fehlerbehandlung
-    * **Legacy APIs**: `receiveEvents()` mit Flux<T> (deprecated)
+- **`EventConsumer` Interface**: Definiert APIs für das Empfangen von Domain Events
+  - **Moderne APIs**: `receiveEventsWithResult()` mit Flow<Result<T>> für typsichere Fehlerbehandlung
+  - **Legacy APIs**: `receiveEvents()` mit Flux<T> (deprecated)

-* **`KafkaEventPublisher`**: Implementierung des EventPublisher mit umfassendem Feature-Set
-    * Reaktive, nicht-blockierende Kafka-Integration mit `ReactiveKafkaProducerTemplate`
-    * Intelligente Retry-Logic mit exponential backoff
-    * Optimierte Batch-Verarbeitung mit kontrollierbarer Parallelität (10 concurrent operations)
-    * Comprehensive Logging und Progress-Tracking
+- **`KafkaEventPublisher`**: Implementierung des EventPublisher mit umfassendem Feature-Set
+  - Reaktive, nicht-blockierende Kafka-Integration mit `ReactiveKafkaProducerTemplate`
+  - Intelligente Retry-Logic mit exponential backoff
+  - Optimierte Batch-Verarbeitung mit kontrollierbarer Parallelität (10 concurrent operations)
+  - Comprehensive Logging und Progress-Tracking

-* **`KafkaEventConsumer`**: Implementierung des EventConsumer mit erweiterten Funktionen
-    * Connection-Pooling zur Wiederverwendung von KafkaReceiver-Instanzen
-    * Sichere Deserialisierung mit Trusted-Package-Validierung
-    * Manual Acknowledgment Control für bessere Kontrolle über Commit-Verhalten
-    * Consumer-Cache-Management für Ressourcenoptimierung
+- **`KafkaEventConsumer`**: Implementierung des EventConsumer mit erweiterten Funktionen
+  - Connection-Pooling zur Wiederverwendung von KafkaReceiver-Instanzen
+  - Sichere Deserialisierung mit Trusted-Package-Validierung
+  - Manual Acknowledgment Control für bessere Kontrolle über Commit-Verhalten
+  - Consumer-Cache-Management für Ressourcenoptimierung

-* **`MessagingError` Hierarchie**: Domain-spezifische Fehlertypen für strukturierte Fehlerbehandlung
-    * `SerializationError`, `DeserializationError`: Serialization-/Deserialization-Probleme
-    * `ConnectionError`: Netzwerk- und Verbindungsfehler
-    * `TimeoutError`: Zeitüberschreitungen
-    * `AuthenticationError`: Authentifizierungs-/Autorisierungsfehler
-    * `TopicConfigurationError`: Topic-Konfigurationsprobleme
-    * `UnexpectedError`: Allgemeine unerwartete Fehler
+- **`MessagingError` Hierarchie**: Domain-spezifische Fehlertypen für strukturierte Fehlerbehandlung
+  - `SerializationError`, `DeserializationError`: Serialization-/Deserialization-Probleme
+  - `ConnectionError`: Netzwerk- und Verbindungsfehler
+  - `TimeoutError`: Zeitüberschreitungen
+  - `AuthenticationError`: Authentifizierungs-/Autorisierungsfehler
+  - `TopicConfigurationError`: Topic-Konfigurationsprobleme
+  - `UnexpectedError`: Allgemeine unerwartete Fehler

-#### Vorteile:
+#### Vorteile

-* **Typsichere Fehlerbehandlung**: Result Pattern eliminiert unerwartete Exceptions
-* **Flexible APIs**: Sowohl moderne Coroutine-basierte als auch Legacy reaktive APIs
-* **Production-Ready**: Umfassendes Retry-Management, Observability und Ressourcenoptimierung
-* **Domain-Driven Design**: Explizite Fehlertypen und saubere Abstraktionen
+- **Typsichere Fehlerbehandlung**: Result Pattern eliminiert unerwartete Exceptions
+- **Flexible APIs**: Sowohl moderne Coroutine-basierte als auch Legacy reaktive APIs
+- **Production-Ready**: Umfassendes Retry-Management, Observability und Ressourcenoptimierung
+- **Domain-Driven Design**: Explizite Fehlertypen und saubere Abstraktionen

 ## Verwendung

@@ -81,6 +79,7 @@ Ein Microservice, der Nachrichten senden oder empfangen möchte, deklariert eine
 ### Moderne API (Result Pattern + Coroutines) - **Empfohlen**

 **Beispiel für das Senden einer Nachricht mit typsicherer Fehlerbehandlung:**
+
 ```kotlin
@Service
 class EventNotificationService(
@@ -113,6 +112,7 @@ class EventNotificationService(
 ```

 **Beispiel für das Empfangen von Nachrichten mit typsicherer Fehlerbehandlung:**
+
 ```kotlin
@Component
 class ModernEventListener(
@@ -175,6 +175,7 @@ class ModernEventListener(
 ```

 **Beispiel für Consumer mit Coroutines und strukturierter Parallelität:**
+
 ```kotlin
@Service
 class BatchEventProcessor(
@@ -215,6 +216,7 @@ class BatchEventProcessor(
 ### Legacy Reactive API - **Wird depreciert**

 **Beispiel für das Senden einer Nachricht (reaktiv, nicht-blockierend):**
+
 ```kotlin
@Service
 class LegacyEventNotificationService(
@@ -235,6 +237,7 @@ class LegacyEventNotificationService(
 ```

 **Beispiel für das Empfangen von Nachrichten (reaktiv):**
+
 ```kotlin
@Component
 class EventListener(
@@ -433,54 +436,54 @@ dependencies {
 Die Zuverlässigkeit des Moduls wird durch eine mehrstufige Teststrategie sichergestellt, die sowohl Unit- als auch Integrationstests umfasst:

 ### Integrationstests (Goldstandard)
-* **Testcontainers**: Der `KafkaIntegrationTest` startet einen echten Apache Kafka Docker-Container, um die Funktionalität unter realen Bedingungen zu validieren
-* **Reaktives Testen**: Nutzt Project Reactor's `StepVerifier` für deterministische Tests der reaktiven Streams ohne unzuverlässige Thread.sleep-Aufrufe
-* **Lifecycle Management**: Saubere Ressourcenverwaltung über @BeforeEach und @AfterEach für korrekte Freigabe von Producer-Threads
-* **End-to-End Validierung**: Vollständige Publish-Subscribe-Zyklen mit echtem Kafka-Cluster
+- **Testcontainers**: Der `KafkaIntegrationTest` startet einen echten Apache Kafka Docker-Container, um die Funktionalität unter realen Bedingungen zu validieren
+- **Reaktives Testen**: Nutzt Project Reactor's `StepVerifier` für deterministische Tests der reaktiven Streams ohne unzuverlässige Thread.sleep-Aufrufe
+- **Lifecycle Management**: Saubere Ressourcenverwaltung über @BeforeEach und @AfterEach für korrekte Freigabe von Producer-Threads
+- **End-to-End Validierung**: Vollständige Publish-Subscribe-Zyklen mit echtem Kafka-Cluster

 ### Unit Tests
-* **`KafkaEventPublisherErrorTest`**: Fokussierte Tests für Fehlerbehandlung mit MockK für isolierte Testszenarien
-* **Fehlerszenarien**: Systematische Tests für Serialization-, Authentication-, Connection- und Timeout-Fehler
-* **Batch-Verarbeitung**: Validierung von Batch-Operationen und Empty-Batch-Handling
-* **Retry-Logic**: Tests für intelligente Retry-Mechanismen und Retry-Exhaustion
+- **`KafkaEventPublisherErrorTest`**: Fokussierte Tests für Fehlerbehandlung mit MockK für isolierte Testszenarien
+- **Fehlerszenarien**: Systematische Tests für Serialization-, Authentication-, Connection- und Timeout-Fehler
+- **Batch-Verarbeitung**: Validierung von Batch-Operationen und Empty-Batch-Handling
+- **Retry-Logic**: Tests für intelligente Retry-Mechanismen und Retry-Exhaustion

 ### Sicherheits- und Konfigurationstests
-* **`KafkaSecurityTest`**: Validierung der Sicherheitskonfigurationen und Trusted-Package-Verwaltung
-* **`KafkaEventConsumerCacheTest`**: Tests für Consumer-Caching und Ressourcenoptimierung
-* **Konfigurationsvalidierung**: Automatische Validierung aller Konfigurationsparameter
+- **`KafkaSecurityTest`**: Validierung der Sicherheitskonfigurationen und Trusted-Package-Verwaltung
+- **`KafkaEventConsumerCacheTest`**: Tests für Consumer-Caching und Ressourcenoptimierung
+- **Konfigurationsvalidierung**: Automatische Validierung aller Konfigurationsparameter

 ## Neue Features und Optimierungen (2025)

 ### Domain-Driven Design (DDD) Integration
-* **Result Pattern APIs**: Neue suspending Coroutine-basierte APIs mit typsicherer Fehlerbehandlung über das Result Pattern
-* **Domain-spezifische Fehlertypen**: Umfassende `MessagingError` Hierarchie (SerializationError, ConnectionError, TimeoutError, AuthenticationError, etc.)
-* **Explizite Fehlerbehandlung**: Eliminiert unerwartete Exceptions durch strukturierte Fehler-Typen
-* **Backward Compatibility**: Legacy-reactive APIs bleiben verfügbar, sind aber als deprecated markiert
+- **Result Pattern APIs**: Neue suspending Coroutine-basierte APIs mit typsicherer Fehlerbehandlung über das Result Pattern
+- **Domain-spezifische Fehlertypen**: Umfassende `MessagingError` Hierarchie (SerializationError, ConnectionError, TimeoutError, AuthenticationError, etc.)
+- **Explizite Fehlerbehandlung**: Eliminiert unerwartete Exceptions durch strukturierte Fehler-Typen
+- **Backward Compatibility**: Legacy-reactive APIs bleiben verfügbar, sind aber als deprecated markiert

 ### Erweiterte Konfigurationsvalidierung
-* **Automatische Validierung**: Alle Konfigurationsparameter werden automatisch bei der Zuweisung validiert
-* **Bootstrap-Server-Format**: Unterstützt sowohl einfache (`host:port`) als auch protokoll-präfixierte Formate (`PLAINTEXT://host:port`)
-* **Sicherheitsfeatures**: Konfigurierbare Sicherheitsfunktionen für Produktionsumgebungen
-* **Connection-Pool-Management**: Konfigurierbare Verbindungspool-Größe für bessere Ressourcenverwaltung
+- **Automatische Validierung**: Alle Konfigurationsparameter werden automatisch bei der Zuweisung validiert
+- **Bootstrap-Server-Format**: Unterstützt sowohl einfache (`host:port`) als auch protokoll-präfixierte Formate (`PLAINTEXT://host:port`)
+- **Sicherheitsfeatures**: Konfigurierbare Sicherheitsfunktionen für Produktionsumgebungen
+- **Connection-Pool-Management**: Konfigurierbare Verbindungspool-Größe für bessere Ressourcenverwaltung

 ### Verbesserte Observability
-* **Strukturierte Logs**: Erweiterte Logging-Informationen mit GroupID, Timestamps und Event-Kontext
-* **Fehlerkontext**: Detaillierte Fehlerinformationen mit Retry-Status und Event-Type-Details
-* **Performance-Tracking**: Bessere Nachvollziehbarkeit von Batch-Operationen und Retry-Versuchen
-* **Batch-Progress-Logging**: Automatisches Progress-Logging bei großen Batch-Operationen (alle 100 Events)
+- **Strukturierte Logs**: Erweiterte Logging-Informationen mit GroupID, Timestamps und Event-Kontext
+- **Fehlerkontext**: Detaillierte Fehlerinformationen mit Retry-Status und Event-Type-Details
+- **Performance-Tracking**: Bessere Nachvollziehbarkeit von Batch-Operationen und Retry-Versuchen
+- **Batch-Progress-Logging**: Automatisches Progress-Logging bei großen Batch-Operationen (alle 100 Events)

 ### Robustheit-Verbesserungen
-* **Intelligente Retry-Logik**: Differenzierte Retry-Strategien basierend auf Fehlertypen (keine Retries für Serialization/Auth-Fehler)
-* **Exponential Backoff**: Konfigurierbare Retry-Delays mit exponential backoff (1s initial, max 10s backoff)
-* **Controlled Batch Concurrency**: Optimierte Batch-Verarbeitung mit konfigurierbarer Parallelität (Standard: 10 concurrent operations)
-* **Testcontainer-Kompatibilität**: Vollständige Kompatibilität mit Docker-basierten Tests
-* **Enhanced Error Handling**: Verbesserte Fehlerbehandlung mit strukturierten Kontext-Informationen
+- **Intelligente Retry-Logik**: Differenzierte Retry-Strategien basierend auf Fehlertypen (keine Retries für Serialization/Auth-Fehler)
+- **Exponential Backoff**: Konfigurierbare Retry-Delays mit exponential backoff (1s initial, max 10s backoff)
+- **Controlled Batch Concurrency**: Optimierte Batch-Verarbeitung mit konfigurierbarer Parallelität (Standard: 10 concurrent operations)
+- **Testcontainer-Kompatibilität**: Vollständige Kompatibilität mit Docker-basierten Tests
+- **Enhanced Error Handling**: Verbesserte Fehlerbehandlung mit strukturierten Kontext-Informationen

 ### Test-Suite Optimierung
-* **Fokussierte Unit Tests**: Bereinigte Test-Suite mit Fokus auf essentielle Funktionalität
-* **MockK Integration**: Moderne Mocking-Frameworks für isolierte Unit Tests
-* **StepVerifier Korrekturen**: Korrigierte reaktive Test-Assertions für `Mono<Unit>` Rückgabetypen
-* **Reduced Test Complexity**: Entfernung unnötiger Performance- und Logging-Tests zugunsten fokussierter Funktionstests
+- **Fokussierte Unit Tests**: Bereinigte Test-Suite mit Fokus auf essentielle Funktionalität
+- **MockK Integration**: Moderne Mocking-Frameworks für isolierte Unit Tests
+- **StepVerifier Korrekturen**: Korrigierte reaktive Test-Assertions für `Mono<Unit>` Rückgabetypen
+- **Reduced Test Complexity**: Entfernung unnötiger Performance- und Logging-Tests zugunsten fokussierter Funktionstests

 ## Troubleshooting

@@ -493,6 +496,7 @@ Die Zuverlässigkeit des Moduls wird durch eine mehrstufige Teststrategie sicher
 **Mögliche Ursachen und Lösungen**:

 1. **Kafka-Cluster-Erreichbarkeit prüfen**:
+
 ```bash
 # Teste Verbindung zu Kafka-Cluster
 telnet kafka-cluster 9092
@@ -502,12 +506,14 @@ nc -zv kafka-cluster 9092
 ```

 2. **Bootstrap-Server-Konfiguration validieren**:
+
 ```kotlin
 // Multiple Broker für High Availability
 kafkaConfig.bootstrapServers = "kafka-01:9092,kafka-02:9092,kafka-03:9092"
 ```

 3. **Netzwerk-Timeouts erhöhen für langsame Verbindungen**:
+
 ```kotlin
 // Producer-Konfiguration erweitern
 override fun producerConfigs(): Map<String, Any> = super.producerConfigs() + mapOf(
@@ -521,6 +527,7 @@ override fun producerConfigs(): Map<String, Any> = super.producerConfigs() + map
 **Problem**: `MessagingError.DeserializationError` beim Empfangen von Nachrichten

 **Lösungsansätze**:
+
 ```kotlin
 // 1. Trusted Packages erweitern
 kafkaConfig.trustedPackages = "at.mocode.*,com.mycompany.*,java.util.*"
@@ -544,6 +551,7 @@ private suspend fun handlePoisonMessage(topic: String, error: MessagingError.Des
 **Problem**: Langsame Message-Verarbeitung oder hohe Latenz

 **Optimierungsstrategien**:
+
 ```kotlin
 // 1. Connection Pool vergrößern
 kafkaConfig.connectionPoolSize = 50
@@ -568,6 +576,7 @@ suspend fun processEventsBatch(events: List<EventDetails>) {
 **Problem**: Speicherverbrauch steigt kontinuierlich

 **Lösungen**:
+
 ```kotlin
 // 1. Consumer-Cache korrekt verwalten
@PreDestroy
@@ -696,6 +705,7 @@ A: Die moderne API nutzt das Result Pattern für explizite Fehlerbehandlung und
 **Q: Wann sollte ich Batch-Verarbeitung verwenden?**

 A: Batch-Verarbeitung ist empfohlen bei:
+
 - Mehr als 10 Events pro Sekunde
 - Hoher Netzwerk-Latenz zum Kafka-Cluster
 - Events, die zusammen verarbeitet werden können
@@ -703,6 +713,7 @@ A: Batch-Verarbeitung ist empfohlen bei:
 **Q: Wie handle ich Backpressure bei hohem Event-Durchsatz?**

 A: Nutzen Sie die eingebauten Flow-Operatoren:
+
 ```kotlin
 eventConsumer.receiveEventsWithResult(topic, EventType::class.java)
    .asFlow()
@@ -715,8 +726,6 @@ eventConsumer.receiveEventsWithResult(topic, EventType::class.java)

 **Letzte Aktualisierung**: 15. August 2025

-
-
 ## Aktualisierungen (September 2025)

 - ReactiveKafkaConfig: Der Bean kafkaConfig() ist jetzt mit @ConditionalOnMissingBean annotiert. Dadurch wird kein zweiter KafkaConfig-Bean erzeugt, wenn bereits extern einer bereitgestellt wird. Dies verhindert Bean-Kollisionen und erleichtert Überschreibungen in Services/Tests.
@@ -49,6 +49,7 @@ management.zipkin.tracing.endpoint=http://zipkin:9411/api/v2/spans
 ```

 Hinweise:
+
 - Sampling-Rate: In Entwicklung 1.0 (100%). In Produktion sollte dies reduziert werden (z. B. 0.1).
 - Endpunkte: Der Prometheus-Scrape-Pfad ist einheitlich `/actuator/prometheus`.
 - Überschreibung: Jede Anwendung kann diese Werte über application.yml/-properties anpassen.