From our practice: References, use cases, and industry feedback
Learn more about how PROTOS is already supporting public transport in Germany.
Typical architectural patterns that are slowing things down today
When you look at the infrastructure of many transport companies, the same patterns emerge time and time again:
- Monolithic sales systems
A central ticketing system in which fares, products, validity periods, payment methods, interfaces, and reporting are closely intertwined. Changes to one part pose a risk to the entire system. - Directly connected point-to-point interfaces
Individual interfaces are built for each new integration (e.g., association, partner, clearing house). The result: a difficult-to-maintain interface zoo. - On-premise infrastructure with static capacity
Peak loads—e.g., during disruptions or fare changes—lead to performance problems because systems do not scale elastically. - Lack of multi-tenancy
As soon as multiple transport companies, fare zones, or partners need to be integrated, many systems reach their limits when it comes to meeting compliance and data protection requirements.
These patterns have understandably developed over time, but they are no longer compatible with the requirements of networked, digital mobility.

The biggest problem with many public transport digitization projects is not the app, but a backend that was never built for real-time, partner integration, or dynamic pricing. Our goal is to create an architecture that can be flexibly expanded instead of blocking every change. The solution lies in clear domains, microservices, and an API layer that finally brings order to the structures that have grown over time.
How a cloud-native public transport platform could look in the backend
Instead of monolithic systems, public transport needs a service-oriented, API-centric, and cloud-native architecture that includes the following core components:
- API gateway for clear, versioned, and secure external interfaces (apps, portals, partners).
- Microservices for clearly defined domains such as pricing, product catalog, ticket lifecycle, user accounts, reporting.
- Event streaming backbone (e.g., Kafka) for real-time events such as trips, check-ins, validations, cancellations.
- Multi-tenant clearing and billing components that logically separate multiple transport companies and associations but can be operated jointly from a technical perspective.
- Observability stack (logs, metrics, traces) to detect failures and performance issues early and fix them in a targeted manner.
- Infrastructure-as-Code and automated deployments to roll out changes reliably and reproducibly.
Example reference architecture (simplified)

The graphic above shows the model for the solution. When topics such as multi-tenancy are added, databases and microservices must be provided more frequently. This distribution and scaling can be easily achieved with Terraform.
Read top references now
The path from today to tomorrow’s cloud backend
Completely replacing existing systems is neither realistic nor sensible. Successful projects instead follow an incremental migration path:
- Creating transparency
- Inventory of existing systems and interfaces
- Identification of critical paths (ticket purchase, real-time data, clearing)
- Introducing an API-first layer
- Introducing an API gateway in front of existing core systems
- Decoupling front-end development and legacy systems
- Introducing microservices based on specific use cases
- e.g., starting with “products & fares” or “ticket lifecycle”
- Synchronize data, set up initial events
- Establish event streaming
- Central event platform for journeys, tickets, inspections, disruptions
- Gradual conversion from batch to event processes
- Gradually remove legacy functions
- Break down monolith into individual domains
- Replace old functions with cloud services

We see the same technical debt burden in almost every project: monoliths without scaling, manual deployments, no observability. When the schedule is tight, rebooting the data center won’t help. Our goal is an operational foundation that scales automatically, monitors itself, and rolls out securely. With cloud-native patterns and infrastructure-as-code, this is finally becoming a reality.
How PROTOS supports public transport companies
PROTOS supports public transport companies and associations in pursuing this path in a technically safe and organizationally realistic manner:
- Architectural design of cloud-native public transport backends
- Setting up API gateways and event streaming platforms
- Migrating ticketing, billing, and fare calculation functions
- Operating the cloud infrastructure, including monitoring, security, and cost control
Anyone who is serious about digitalization in public transport cannot avoid modernizing their backend. The good news is that with the right architecture and a clear migration path, the way forward is feasible – and this is exactly where PROTOS comes in.




