June 16, 2017 Adam Turnbull

London Bike Hire Station Real-Time Update Application – Use Case

In July of 2010, the London Bike Hire Scheme, operated under Transport for London (TfL), was launched. Over the years the characteristic bicycles have become an integral part of London transport, beside the London Tube, black cabs and red double-decker buses. Today the scheme consists of approximately of 800 bike stations, 13,500 (1) bicycles and 250,000 (2) registered members. In 2016, an average of 28,000 rides were taken every day(3). While these figures are impressive, there remains large growth potential when comparing the number of registered members (250k) to the total population living in, working in, and visiting London.

An analysis of the London Bike Hire scheme identified two problems that could prevent increased bike hire by more Londoners and visitors. These problems are: lack of information regarding proximity to customers’ locations of bike stations with bike availability, and open docking slot availability at particular stations:

  1. If a user plans to make a journey or part of it with the hired bicycle, it is necessary to know the location of the closest bike station and if there are bikes for hire available. Without this information he could find out that his chosen bike station has no bikes and he will need to continue his journey walking or using another form of public transport or he will need to go to a different bike station. This might mean that he will be late to his destination.
  2. The first 30min of the ride is free of charge and customers might want to use this time to commute between bike stations A and B. However, there is a risk that station B has no empty slots to dock the bike. Again the user might be forced to find another bike station and to pay late return fee.

Providing users with the above information can increase user confidence in the system and deliver an improved user experience, thereby increasing system-wide usage of London Bike Hire.

Further, system-wide utilization of the bicycles can be improved, as users can adapt to the situation where there are no bikes available at a particular station, by choosing an alternate nearby station when planning the journey.


When designing an application to provide the above information, creators must take into account a large number of potential requests to the server from a large user base, and the changing nature of that information. This is especially important during peak periods of the day (rush hours), when most rides are taking place. Push Technology’s real-time, streaming data platform, Diffusion™, excels in managing high-volume, variable-quantity data over unreliable networks – the Internet.  Diffusion allows many clients (users)  to subscribe to data sources (topics) and its sophisticated algorithm, based on data changes (deltas), allows for optimal use of the bandwidth. In simple terms, Diffusion manages the data communications, in real-time, for the system/consumer interface, and can address the London Bike for Hire system challenges.  In such a pattern, some clients (or one client) are responsible for the data publishing and other clients are subscribers who receive the data. Diffusion makes this pattern work at a large scale – with frequent updates and many subscribers.

Conveniently, the TfL public API provides rich real-time data for bike stations. This limits the role of the architecture to interpreting the data and providing a scalable and optimal access point to the data for a large volume of subscribers.

The structure of the project consists of three parts:

  1. Diffusion publishing client – an application responsible for creating a topic for each bike station and updating it with data pulled from the TfL public API.
  2. Diffusion server – the middle-man responsible for providing infrastructure for topic updates and subscribing clients.
  3. Diffusion subscribing client – a web and/or mobile application which receives data from the Diffusion server in real time and provides a UI for the customer.

Diffusion includes APIs that allow you to build fully functional applications. Only a short amount of time is needed to learn the Diffusion API, and its rich capabilities and customization options allow for configuration and adaptation to the specific needs of more advanced architectures.

Construction of a simple Diffusion Java client is abstracted to an object initialization:

after which its functionalities are available through session features, for example:


The role of the publisher is to get data describing bike stations from the TfL API, to transform the data, and to push it to the Diffusion server. Data is organized in topics, where each topic represents a single bike station.

Diffusion offers support for different data serialization types; however, in this project JSON will be used as it is a standard format for data sent over the Internet. A simple declaration of the data type when a topic is created ensures that the topic is of JSON type:

When the publisher starts, it creates a topic tree with all of London Bike Hire’s stations. The TfL API offers a simple request end point to get a complete list of them. Then the publisher pulls data from the TfL API in 5min intervals and updates topics on the Diffusion server. The interval is dictated by the limitation of the TfL API, which updates the status of bike stations every 5min.

Diffusion server

The Diffusion server is the heart of the system. It receives updates from a publisher and sends updates to the subscribers. Key to optimizing data communication efficiency is that the Diffusion server sends only deltas, or changes in data, to subscribers. This is a critical attribute for high-scale solutions, as it provides optimal bandwidth utilization.


The last component of the system is a subscribing client, which provides the interface for the user to check the status of nearby bike stations. The subscribing client application has an interactive interface which uses Google Maps to display the location of the stations. The client application offers the user the ability to see bike stations in the 500m proximity of a tube station.

or in proximity to a location clicked on the map.

The user-selected location is represented by the blue marker on the map and bike station locations are represented by markers whose color reflects the number of bikes available for hire:

  • green – OK, over 20 bikes
  • yellow – Warning, between 1 and 19 bikes
  • red – Alarm, no bikes

The application also provides additional detailed information about a particular bike station when the user clicks on the bike station marker. The status color changes in real time based upon the updates received from the Diffusion server.

This client application has been written with use of javafx, GMapsFX(4) framework and the Diffusion Java SDK as a proof of concept. However, Diffusion offers support for many different platforms (including Android, iOS and JavaScript) and porting the application to a mobile app would require minimal effort.

A code repository of the project can be found at https://bitbucket.org/pushtechnology/tfl-bike-stations-demo.


Enjoy the rich functionality of Diffusion 6.7 as part of your event-driven application.

Quick Start Guide

Step-by-step guide to getting started.

Diffusion Cloud

SaaS offering that focuses on business.

Diffusion On-Premise

A pub-sub platform for real-time applications.