Skip to main content
Version: 2.0.0

ADR 009: Data Mgmt Portal | Backend Framework

Date: 2025-09-23

Status: Accepted

Decision Makers: @jonasfrz @lukas.wydra

Context​

For the backend of the Data Management PortalManagement PortalThe central user interface of the Platform that provides access to all functionalities for managing data, configurations, users, and access. It serves as the main entry point for working with data-related elements., we need to decide which Java framework will serve as the foundation. The goal is to ensure a scalable, maintainable, and extensible architecture that balances operational efficiency with developer productivity.

Two options were evaluated: Quarkus and Spring Boot.

  • Quarkus: designed cloud-native and container-first, with very fast startup times and low resource usage. Strong fit for serverless, high-density environments, or architectures with many small, short-lived services.
  • Spring Boot: mature ecosystem, broad adoption, extensive libraries and integrations, with strong community and operational tooling. The team has deep experience with Spring, reducing learning curve and risk.

Checked Architecture Principles​

  • Model-centric data flow: Full – Spring’s ecosystem (Spring Data, JPA, etc.) supports model-driven workflows.
  • Distributed architecture with unified user experience: Partial – both frameworks support microservices and distributed setups, but a unified experience requires additional components (e.g., API gateway, service discovery,..).
  • Modular design: Full – Spring Boot enables modular microservice architecture, Quarkus too, but Spring is more established for enterprise modularity.
  • Integration capability through defined interfaces: Full – Spring has strong integration capabilities via Spring Cloud, messaging, and connectors.
  • Open source as the default: Full – both frameworks are open source.
  • Cloud-native architecture: Partial – Quarkus is stronger in this area, but Spring Boot is cloud-ready with Spring Cloud.
  • Prefer standard solutions over custom development: Full – Spring Boot’s ecosystem provides many proven, ready-to-use components.
  • Self-contained deployment: Full – both frameworks provide containerized, self-contained deployments.
  • Technological consistency to ensure maintainability: Full – The backend, built with Spring Boot, provides consistency in our development and operations. External integrations are done via REST APIs, making the external product's technology stack irrelevant.
  • Multi-tenancy: Full – both frameworks can fully support multi-tenancy, though actual implementation depends on system design.
  • Security by design: Full – Spring Security provides mature and extensive security capabilities.

Decision​

Use Spring Boot as the backend framework for the Data Management PortalManagement PortalThe central user interface of the Platform that provides access to all functionalities for managing data, configurations, users, and access. It serves as the main entry point for working with data-related elements..

Key reasons:

  • Larger ecosystem of libraries, integrations, and community support.
  • Mature and widely adopted operational tooling (e.g., Spring Boot Actuator, monitoring, diagnostics).
  • Team has strong expertise in Spring, reducing training effort and risks.
  • Portal requirements focus on stability, extensibility, and maintainability, not on cold-start optimization or high-density serverless workloads.

Consequences​

  • We benefit from faster development speed thanks to team experience and the extensive Spring ecosystem.
  • Runtime resource usage may be somewhat higher compared to Quarkus, but the portal’s workload does not require extreme optimization.
  • Migration to Quarkus later is possible but would involve non-trivial changes, especially in areas like dependency injection, configuration, and extensions.

Alternatives​

  • Quarkus: would be the preferred choice if the portal required:
    • very high pod density / strict CPU & memory budgets,
    • cold-start–critical workloads (serverless, FaaS, batch jobs, edge),
    • many small, short-lived services instead of long-running ones.

See also​