- STIP - Stockholm Transit Intelligence Platform
- Project Description
- Technology
- Access the Project - STIP
- Software Architecture
- Authors and acknowledgment
STIP – Stockholm Transit Intelligence System is a data-intensive, AI-driven system designed to improve public transport travel in Stockholm by combining traditional route planning with intelligent delay prediction. Unlike conventional journey planners that assume services run according to schedule, STIP acknowledges that delays are a regular part of everyday commuting and uses historical data, real-time data and machine learning to estimate how reliable a planned trip is likely to be.
The system integrates with public transit data sources provided through the TrafikLab platform (including ResRobot APIs) to retrieve routes, stops, lines, directions, and scheduled travel times. When a user searches for a trip, STIP provides possible options, including walking segments, bus routes, transfers, and total travel time. On top of this baseline route information, STIP applies machine-learning models trained on historical delay data to predict potential delays for relevant bus segments.
STIP also supports user accounts and personalization. Registered users can save favorite stops, routes, or recurring trips that reflect their regular travel patterns. This enables the system to deliver more relevant information, such as highlighting predicted delays that affect a user's typical commute rather than showing generic disruptions. In addition, the system can monitor saved travel patterns and trigger notifications when significant delays are expected.
STIP is implemented as a microservice-based system deployed on Google Kubernetes Engine. The frontend communicates with backend services via RESTful HTTP through load balancers, while background monitoring and notifications are handled asynchronously using RabbitMQ. Persistent data storage is maintained in service-specific databases backed by Postgres, and the architecture supports training and retraining multiple machine-learning model versions, enabling continuous improvement as new data becomes available.
Overall, STIP aims to make public transport travel in Stockholm more predictable and transparent by helping users not only choose a route, but also understand how reliable that route is likely to be. Official schedules rarely match reality. STIP helps commuters leave at the right time, avoid missed connections, and reduce stress: saving minutes every day.
STIP - link to web application
The system uses a Python-based backend with Django, PostgreSQL, and RabbitMQ, integrates public transport data via Trafiklab and ResRobot APIs, and provides a React and TypeScript frontend. Machine learning models are implemented in Python for delay prediction. The application is containerized with Docker and deployed on Kubernetes (GKE), with testing supported by Pytest and Postman.
- Python 3
- Django & Django REST Framework
- PostgreSQL
- RabbitMQ
- TrafikLab / ResRobot API integration
- Docker
- Google Kubernetes Engine (GKE)
- Python
- Scikit-learn
- XGBoost
- pandas
- Historical transit data for training and prediction
- Docker containers
- Kubernetes (GKE)
- pika (RabitMQ client)
The application is fully deployed using Kubernetes on Google Cloud Platform (Google Kubernetes Engine). All backend services, machine learning components, and the frontend are containerized and orchestrated through Kubernetes, ensuring scalability and reliability.
The system is publicly accessible via the following URL:
Note: For Admin access and credentials: see final report or contact team
STIP - link to web application
No local setup is required to access the deployed version. Simply open the link in a web browser to use the application.
Running STIP locally requires extensive manual setup due to its Kubernetes-native architecture. The process involves multiple configuration steps and can take over an hour to complete initial setup.
- Minikube
- kubectl
- Docker Desktop
- At least 4GB RAM allocated to Minikube
Running STIP locally involves the following steps:
- Install and start Minikube
minikube start --memory=4096 --cpus=2 --driver=docker-
Configure secrets
- Update
k8s/secrets.yamlwith your local credentials - Update database connection strings
- Configure RabbitMQ credentials
- Add API keys for external services
- Update
-
Build all backend service images
eval $(minikube docker-env)
docker build -t user-service:latest ./user-service
docker build -t ml-service:latest ./ml-service
docker build -t notification-service:latest ./notification-service
docker build -t polling-service:latest ./polling-service
docker build -t travel-planner-service:latest ./travel-planner-service- Apply Kubernetes manifests
kubectl apply -f k8s/- Get service URLs and build frontend
# Get the URLs for each service
minikube service user-service --url
minikube service travel-planner-service --url
minikube service ml-service --url
# Build frontend with these URLs
docker build \
--build-arg VITE_USER_API_URL=http://<user-service-url> \
--build-arg VITE_TRAVEL_API_URL=http://<travel-planner-url> \
--build-arg VITE_ML_API_URL=http://<ml-service-url> \
-t frontend:latest ./frontend-
Update frontend deployment
- Modify
k8s/frontend-deployment.yamlwith the correct service IPs - Apply the updated configuration:
kubectl apply -f k8s/frontend-deployment.yaml
- Modify
-
Run initialization scripts ⏱️ (~1 hour)
# Initialize polling service (fetches and processes GTFS static data)
kubectl exec deployment/polling-service -- python manage.py load_gtfs_static
# Initialize travel planner service (builds route database)
kubectl exec deployment/travel-planner-service -- python manage.py build_bus_dbThese commands download and process Stockholm transit data, which takes approximately one hour to complete.
- Verify deployment
kubectl get pods
minikube service frontend --urlDue to the complexity of local setup, we recommend:
- Viewing the live demo at http://34.88.58.9/
- Reviewing the codebase and architecture documentation
- Contacting the team for a guided walkthrough
For development of individual services, consider setting up a simplified Docker Compose environment for the specific service you're working on.
Below is extensive coverage of STIP component diagram. (Open seperate tab to see full information)
Component Diagram
This component diagram represents a microservice-based architecture for STIP (Stockholm Transit Intelligence System). The system is deployed on Google Kubernetes Engine (GKE) and is composed of multiple independently deployable microservices, frontend and backend load balancers for request routing, persistent databases, and a RabbitMQ message broker for asynchronous communication. Some details of the architecture are as follows:
User Interface
The system has a browser-based frontend, which serves as the main user interface for route planning, delay prediction, and personalization features. The frontend communicates with backend services using RESTful HTTP via a frontend load balancer, which acts as the public entry point to the system.
Load Balancers
The architecture uses multiple load balancers to route traffic within the cluster:
-
A Frontend Load Balancer exposes the frontend to external users.
-
Internal load balancers provide stable access points for backend services, including the User Service, Travel Planner Service, and ML Service. These load balancers enable horizontal scaling and decouple service consumers from individual pod instances.
Microservices
Each microservice in STIP is responsible for a specific domain:
-
User Service: Manages user-related data, including user profiles and saved favorites such as stops, routes, and recurring trips.
-
Travel Planner Service: Handles trip planning requests, retrieves route and schedule data from external transit APIs (TrafikLab/ResRobot), and assembles travel options.
-
ML Service: Provides machine-learning functionality, including delay prediction, model serving, and support for training and retraining predictive models using historical data.
-
Polling Service: Periodically polls external transit APIs and evaluates conditions such as predicted delays on user-favorited routes.
-
Notification Service: Consumes messages related to delay events and sends user notifications, such as email alerts.
Databases
Each core service owns its data and interacts with a dedicated logical database:
-
User database: for user profiles and favorites.
-
Travel Planner database: for route planning–related data.
-
Model/Training database: for historical data, model artifacts, and prediction metadata.
-
Polling database: for polling state and event tracking.
All databases are backed by Postgres, ensuring reliable persistent storage while maintaining clear data ownership per service.
Messaging and Communication
-
Synchronous communication is performed using RESTful HTTP between the frontend and backend services, as well as between services and external transit APIs.
-
Asynchronous communication is handled via RabbitMQ, which decouples the Polling Service from the Notification Service and enables reliable, scalable delivery of notification events.
Overall, this architecture enables STIP to scale individual components independently, integrate machine-learning–based delay prediction seamlessly into route planning, and provide personalized, real-time insights and notifications to users in a reliable and extensible manner.
-
Erik Nisbet (@eriknis)
-
Fredrik Nilsson (@fnilsson)
-
Martin Lidgren (@marlidg)
-
Mohamed Taha Jasser (@mohamedt)
-
Nadman Abdullah Bin Faisal (@nadman)
-
Vaibhav Puram (@puram)
STIP - Stockholm Transit Intelligence Platform - DIT826 H25 - University of Gothenburg, Sweden