The year at Trainline in numbers


2016 has been a very busy year at Trainline as we have been growing at a rapid pace.  This means our tech team has had to work hard to scale effectively and cope with the sheer demand.

New product teams have been springing up all through the year, while older teams have grown and been split into sub-teams to maintain the essential agility of small teams. With such growth, we have needed to ensure our processes were in good shape to manage the increased complexity that this brings.

Here are a few fascinating stats which tell a short story of the year at Trainline … Continue reading

Spotting problems and fixing them before our customers notice

Just over a year ago we were set the challenge of ‘spotting problems and fixing them before our customers notice’. To spot the problems we knew we had to change our behavior from only opening our logs when an issue was suspected, to making them available at the touch of a button to our engineers so it was easy for them to monitor their applications and spot problems and fix them.

Ash Powell’s blog explains how we did this, ‘What the ELK!? – Log Aggregation,‘ and here’s a short film we’ve just completed with Elastic to explain our business and how ELK’s role:

Keeping trainline on track


Continue reading

I’m a Database Developer, this is what I think about data

You are sitting at your screen reading a blog about the death of monolithic databases:


Monolithic databases are so 80s, inflexible, they are an obstacle to change. Referential integrity stops us implementing service orientated architecture, and they cannot be harmonised with continuous delivery”.


And you agree.

Well, you may be right, sometimes, but I assume you don’t agree with the following two statements: Continue reading

Foreign keys – don’t go there.

You’re probably a medium-to-large-sized company, you run a medium-to-large application. You apply all the industry best practices, using micro-/plain-old-service architecture, compartmentalise your system into nice tidy chunks. As they usually do, your DB admin doesn’t like to maintain multiple databases and so you’ve been restricted to run everything under one fairly large database.

One fine day, you decided your data is important, it needs integrity. You decided the best thing to do is to introduce foreign keys.


You may have just made a big architectural mistake

Continue reading