INTRODUCTION
Connecting Switzerland by rail
Swiss Federal Railways SBB (Schweizerische Bundesbahnen SBB) is responsible for running Switzerland’s rail network. It transports more than 1.16 million passengers and 180,000 tons of freight every day. The Swiss network is one of the densest in the world, but running more trains on less track hasn’t impacted punctuality — around 92.5% of trains arrive within three minutes of the intended arrival time.
In addition to maintaining the rail infrastructure, SBB is responsible for running passenger trains and cargo, as well as timetabling trains from other national and international Railway Undertakings (RU).
“At SBB, it’s our responsibility to keep the rail network running smoothly. Our priority is getting people and cargo to the right destination safely and as quickly and easily as possible, which means trains from all RUs need to be treated equally and held to the same high standards,” says Jonas Rüttimann, System Architect at SBB.
The Swiss rail network is heavily used by citizens, so any disruption to services could cause significant inconvenience as well as bringing the densely packed network to a halt.
THE CHALLENGE
Modernizing the database to reduce the risk of downtime
To manage its network, SBB relies on a large amount of data that needs to be highly accessible and accurate. SBB needs this information to find and plan out routes that match the characteristics of a specific train, including the attributes of its cargo. For example, it needs to know how many and what type of carriages are being run with each service, such as first class coaches, bike storage, and restaurant carriages.
This is known as ‘formation data’ and it’s captured from third-party companies via an API. Organizations such as Swiss border control need this data to know what crosses the border in terms of freight, and at what time – which is classed as ‘train running information’.
As the volume of formation data coming into SBB from RUs and its own environment increased, its in-memory database was at an increasing risk of downtime. “The solution’s volatile memory meant that when microservices were restarted following software updates, we had to rebuild the memory every time. We can’t afford to have systems down while that’s happening,” explains Rüttimann.
While SBB minimized disruption by installing fewer releases, it made a strategic decision to look for a document storage solution that supported data persistence as well as being comparably fast to an in-memory database. This would create a future-proof environment and streamline adopting more modern technologies in the future.
