Gesetzliche Krankenversicherung · seit 04/2025

TI-Messenger-Integration für eine gesetzliche Krankenversicherung

Integrationsschicht für den TI-Messenger einer gesetzlichen Krankenversicherung: Chat-Events aus Kafka übernehmen, anreichern, anzeigen und archivieren.

Ausgangslage

80+ Mio.

Versicherte erreichbar

über den TI-Messenger-Standard

Eine gesetzliche Krankenversicherung nutzt den TI-Messenger, einen Matrix-basierten Chat, als Kanal zwischen ihrer Kundenberatung und Versicherten bzw. Leistungserbringern. Die Messenger-Plattform selbst betreibt ein externer Plattformbetreiber. Über den TI-Messenger-Standard sind insgesamt 80+ Mio. Versicherte erreichbar.

Damit die Chats im Arbeitsalltag der Kundenberatung ankommen, braucht es eine Integrationsschicht: Sie muss die Ereignisse der Plattform übernehmen, mit Stammdaten anreichern, für die Beratung anzeigen und revisionssicher archivieren.

Meine Rolle

Ich arbeite im Team als Full-Stack-Entwickler mit Schwerpunkt auf Konzeption und Architektur und übernehme themenbezogen die Rolle des Tech Leads. Ich stimme die technische Spezifikation mit dem Plattformbetreiber ab, bereite Releases vor und dokumentiere die Lösung. Seit 07/2026 kommen Refinement und Review hinzu, außerdem arbeite ich Teammitglieder in neue Themen ein.

Lösung

Gemeinsam mit dem Team baue ich diese Integrationsschicht als Microservices mit Java und Spring Boot 3. Die Plattform liefert die Chat-Ereignisse über Apache Kafka; die Services übernehmen die Events, speichern sie in MongoDB, reichern sie mit Stammdaten an und stellen den Verlauf für die Kundenberatung dar – einschließlich der verschlüsselt in S3 abgelegten Anhänge. Die Anmeldung läuft über Keycloak.

Events, die sich nicht verarbeiten lassen, blockieren den Datenfluss nicht: Sie landen in einer Dead Letter Queue und lassen sich nach einer Korrektur gezielt erneut einspielen.

Betrieben werden die Services auf Kubernetes über fünf Stages, ausgerollt mit Helm und ArgoCD, Secrets als SealedSecrets. Logs laufen nach OpenSearch, Traces nach Jaeger. Architekturentscheidungen – etwa die Datenhaltung in einem eigenen Service – sind als ADRs dokumentiert; für die Geschäftslogik gilt der Anspruch von über 90 % Testabdeckung.

Ergebnis

  • Erstes Release am 24.06.2025 live
  • Fehlerbehandlung über eine Dead Letter Queue seit 07/2025
  • Archiv-Backend seit 15.07.2025 live
  • Fehlgeschlagene Events produktiv nachverarbeitet – u. a. 336 Events am 13.01.2026
  • Release mit Zustellnachweis und verschlüsselten Nachrichten im Juni 2026
  • Rückmeldung des Kunden: sehr zufrieden, Erwartungen übertroffen

Technologien

  • Java
  • Spring Boot 3
  • Apache Kafka
  • MongoDB
  • S3
  • Keycloak
  • Kubernetes
  • Helm
  • ArgoCD
  • SealedSecrets
  • OpenSearch
  • Jaeger