Why modern mobility in public transport is failing due to outdated backends – and how cloud architectures can stabilize the foundation in the long term
Public transport companies have invested heavily in apps and digital front ends in recent years. However, true end-to-end integration—from passenger information to ticket purchasing across transport associations—almost always fails at one point: the backend.
In this article, we show why the digital future of public transport is only possible with consistent backend modernization – and what a cloud-native architecture can look like in concrete terms.
The blind spot of public transport digitization: the backend
Many presentations on the digitization of public transport focus on the user perspective:
- “One app for everything”
- “Real-time information everywhere”
- “Tickets valid across all transport networks”
The reality in IT departments is quite different. These are dominated by:
- Historically developed individual solutions for sales and ticketing
- Network-specific fare and data models
- Monolithic server applications without clear interfaces
- Local data centers with limited scalability
As long as this backend landscape remains largely unchanged, even the most ambitious mobility offerings will remain piecemeal. New features are implemented in months rather than weeks, association boundaries are technically “hard-coded,” and every integration of external partners (e.g., sharing providers) has to be tinkered with individually.
In short, the digitization of public transport is not failing because of a lack of ideas, but because of the reality of the backend.
From our practice: References, use cases, and industry feedback
Learn more about how PROTOS is already supporting public transport in Germany.
- Blog: Digitalization in public transport requires IT infrastructure – otherwise, it will remain patchwork
- Use Case: Generative AI securely at work: automated ticket analysis in AWS Cloud
- Reference: Migration and optimization of a travel platform for the DB Regio Bus
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”, Paul Schmidt, IT Cloud Consultant at PROTOS.
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.
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”, Karsten Quellec, CTO at PROTOS.
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.
