Re-architecting Next Trains

One of the things I have learned from working in data and analytics is that continuous improvement never really ends. Even when something works, there is always another question worth asking:

Can I do this better?

That was the thinking behind the latest update to Next Trains.

Simple for the user. More complicated underneath.

The idea behind Next Trains is deliberately simple.

You save the routes you are interested in, open the app, and the departures you want to know about are there — no swiping, selecting or filtering for stops needed.

That simplicity hides a fairly involved backend workflow.

The application and backend together have to work out which station is relevant, retrieve live rail information for your chosen routes, process it and get the right departures back to your screen. All of this is normally completed within three seconds.

The frontend has had a few minor updates and the backend was working fine. But I thought it could work a lot better.

70–80% better performance

For typical usage, measurements of the backend responses show a 70–80% performance improvement compared with the previous implementation.

The app can make several requests to retrieve the departures it needs, depending on how many routes are relevant to the user’s nearest station. The re-architecture is typically saving hundreds of milliseconds from each of those requests.

So, what did I change?

I started with the workflow

Rather than simply moving the existing backend onto new infrastructure, I wanted to look at how the work was actually being done. The goal was simple:

Get the data to the client as quickly as possible.

That meant looking at each part of the workflow and asking whether it really needed to happen when and where it did.

Run things in parallel

Where two operations don’t depend on each other, there is no reason to make one wait for the other. I changed the workflow so that independent operations can run in parallel, reducing unnecessary waiting.

Move expensive writes later

Some work still needs to happen, but it doesn’t necessarily need to happen before the user gets their departures. I moved those more expensive write operations later in the workflow, taking them out of the critical path. In other words, the user gets the data first, and the backend can finish its other work afterwards.

Streamline the core

I also stripped back the central workflow. The important bit is getting the information the user asked for and returning it as quickly as possible.

Get the data. Process it. Return it.

Anything that doesn’t need to sit in that path has been reconsidered.

Cache more. Control requests better.

I also introduced new caching and rate-limiting mechanisms. Caching means I don’t always have to repeat work that has already been done, while rate limiting gives me better control over requests to the underlying services.

These changes might not sound particularly exciting, but they help keep the core workflow fast and predictable.

A different architecture, not just a different home

Once I had overhauled the backend workflow, I didn’t want to stop there.

A proper re-architecture shouldn’t stop at the code.

So I looked at the technology supporting it too. I revisited the choices behind Next Trains — how the different services fit together, where they run, how they communicate, and which cloud capabilities made the most sense for each part of the workload.

That also meant changing the cloud infrastructure and providers supporting the application.

The result isn’t the old backend moved somewhere else. The technology underneath it has changed as well as the way the workflow operates.

Individually, these changes may save only milliseconds. Together, they make a substantial difference to the overall experience.

The time from opening the app to getting the departures back has gone from around three seconds to around one second.

And that’s really the point. The architecture can be complicated. The experience shouldn’t be.

Open the app. See the departures you want. Know what is happening.

Probably one of the fastest ways to find your platform.

The latest version of Next Trains is available from the Next Trains website.

Based on testing of typical usage. Actual performance will vary depending on device, network conditions and other factors.