Zum Inhalt springen
TixFin

Architektur

Für Zuverlässigkeit gebaut. Für Skalierung gebaut.

Ein Blick auf die technische Architektur hinter der TixFin-Plattform — vom API-Design bis zur Datenpersistenz.

Vier Schichten

Plattform- Stack

Vier Schichten mit je einer Aufgabe — vom Request am Rand bis zum Live-Update auf dem Scanner.

  1. 01

    API-Gateway

    Rate-limitierte, authentifizierte API-Schicht mit TLS, CORS-Regeln und verteiltem Request-Throttling pro Client.

    • Traefik
    • Keycloak
    • OpenID Connect
    • JWT
  2. 02

    Anwendungs-Layer

    Quarkus-basiertes Backend mit Domain-Driven Design, Use-Case-Orchestrierung und isolierten Service-Grenzen pro Modul.

    • Java 21
    • Quarkus
    • Hibernate ORM
    • OpenAPI
  3. 03

    Daten-Layer

    PostgreSQL mit Flyway-verwalteten Migrationen, Redis für verteiltes Caching und MinIO für Objektspeicher.

    • PostgreSQL
    • Flyway
    • Redis
    • MinIO
  4. 04

    Echtzeit-Layer

    WebSocket-Verbindungen für Live-Updates — Ticket-Scans, gemeinsames Bearbeiten von Saalplänen, Operations-Koordination und Support-Chat — plus Server-Sent Events für Benachrichtigungen.

    • WebSockets
    • Server-Sent Events

Wie wir bauen

Engineering- Prinzipien

  • Sicherheit zuerst

    JWT-Authentifizierung, 2FA mit TOTP, WebAuthn-Passkeys, feingranulare RBAC und verteiltes Rate-Limiting auf allen öffentlichen Endpunkten.

  • Containerisiertes Deployment

    Docker-Images, per GitOps auf Kubernetes ausgerollt — mit Health-Endpunkten und strukturiertem Logging für die Produktionsüberwachung.

  • Caching-Strategie

    Dual-Layer-Caching mit Redis und Caffeine. Öffentliche Daten 5 Minuten gecacht mit expliziter Invalidierung bei Mutationen.

  • Observability ab Werk

    Prometheus-Metriken, strukturiertes Logging und automatisch generierte OpenAPI-Dokumentation aus Endpoint-Annotationen.

  • Schema-gesteuerte Migrationen

    Flyway-Datenbankmigrationen stellen konsistente Schema-Evolution über alle Umgebungen sicher.

  • Modulare Architektur

    Domain-Driven Design mit klaren Modulgrenzen. Jede Business-Domäne (Ticketing, Billing, Crew-Ops) ist unabhängig wartbar.

Im Betrieb

So läuft es

Die Infrastruktur unter dem Stack, so wie sie heute konfiguriert ist.

Laufzeit
Container auf einem Kubernetes-Cluster (k3s), deklarativ per GitOps mit Argo CD ausgerollt
Datenbank
PostgreSQL-Cluster, verwaltet vom CloudNativePG-Operator
Backups
Nächtliche Datenbank-Backups in S3-kompatiblen Objektspeicher, 30 Tage aufbewahrt, plus tägliche Cluster-Backups
Transportsicherheit
Durchgängig TLS — Zertifikate stellt cert-manager automatisch aus und erneuert sie
Monitoring
Prometheus-Metriken und Alert-Regeln für den Cluster und die Services darauf

Erlebe es in Aktion

Erkunde die API-Dokumentation oder starte kostenlos in der Beta.