Skip to content
TixFin

Architecture

Built for Reliability. Built for Scale.

A look at the technical architecture powering the TixFin platform — from API design to data persistence.

API DocumentationStart free

Four layers

Platform Stack

Four layers, each with one job — from the request at the edge to the live update on a scanner.

  1. 01

    API Gateway

    Rate-limited, authenticated API layer with TLS, CORS rules and distributed request throttling per client.

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

    Application Layer

    Quarkus-based backend with domain-driven design, use-case orchestration, and isolated service boundaries per module.

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

    Data Layer

    PostgreSQL with Flyway-managed migrations, Redis for distributed caching, and MinIO for object storage.

    • PostgreSQL
    • Flyway
    • Redis
    • MinIO
  4. 04

    Real-Time Layer

    WebSocket connections for live updates — ticket scans, collaborative seatmap editing, operations coordination and support chat — plus server-sent events for notifications.

    • WebSockets
    • Server-sent events

How we build

Engineering Principles

  • Security First

    JWT authentication, 2FA with TOTP, WebAuthn passkeys, fine-grained RBAC, and distributed rate limiting on all public endpoints.

  • Containerized Deployment

    Docker images deployed to Kubernetes through GitOps, with health endpoints and structured logging for production monitoring.

  • Caching Strategy

    Dual-layer caching with Redis and Caffeine. Public data cached for 5 minutes with explicit invalidation on mutations.

  • Observable by Default

    Prometheus metrics, structured logging, and OpenAPI documentation automatically generated from endpoint annotations.

  • Schema-Driven Migrations

    Flyway database migrations ensure consistent schema evolution across all environments.

  • Modular Architecture

    Domain-driven design with clear module boundaries. Each business domain (ticketing, billing, crew ops) is independently maintainable.

In production

How it runs

The infrastructure under the stack, as it is configured today.

Runtime
Containers on a Kubernetes (k3s) cluster, deployed declaratively via GitOps with Argo CD
Database
PostgreSQL clusters managed by the CloudNativePG operator
Backups
Nightly database backups to S3-compatible object storage, kept for 30 days, plus daily cluster backups
Transport security
TLS everywhere, with certificates issued and renewed automatically by cert-manager
Monitoring
Prometheus metrics and alert rules across the cluster and the services on it

See It in Action

Explore the API documentation or start free in the beta.