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.

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.

Jonas Rüttimann, System Architect, SBB

SBB went to market to find a document store database that would integrate well with its existing tech stack. It selected MongoDB Atlas, a multi-cloud developer data platform, and installed it quickly and painlessly. The platform integrates well with other solutions via APIs, making it easy to manage, maintain and build on in the future. “MongoDB is one of the leading data platforms. It’s reliable, and there’s a great community of developers with the necessary skills to manage it,” says Rüttimann.

To reduce the risk of failure associated with a big bang rollout, the team migrated 20 microservices to individual MongoDB clusters over the following two months. This included microservices responsible for processing passenger traffic and freight data, and master data libraries, which record information such as which carriages contain bike racks or access ramps for people with mobility issues.

“We wanted to standardize according to industry-leading technology,” recalls Rüttimann. “It helps to attract and recruit the best developers on the market and keep them working efficiently.”

With MongoDB Atlas, SBB gets all the benefits of a great database with the added bonus of managed services eliminating manual processes and saving time. It can now install updates as soon as they’re available without causing downtime, which gives it access to the latest security patches and features. It no longer needs to manually create backups, which was time-consuming, complicated and risky, and the platform has high availability guaranteed.

MongoDB Atlas has transformed the developer experience, providing a stable, developer-friendly foundation to develop new features quickly and easily with no disruption to the passenger experience. This gives SBB a faster, more reliable environment to support rail service planning.

“We seamlessly transitioned to the new solution without any issues; there hasn’t been a single outage in our first year. My developers have always been keen to use MongoDB and it’s living up to expectations. Now my team is satisfied and no one has any complaints,” says Rüttimann. “We can develop at a speed, safe in the knowledge that it won’t cause any downtime, which gives us the confidence to release new features more often.”

The team also praised the solution’s security and rich feature set, which gives them more agility than the previous database and helps them work smarter every day. For example, if a query is running slowly, the team can pull a report to identify and resolve any issues. And it offers excellent performance, which can be a trade-off when moving from an in-memory to document store database.

“Using MongoDB gives us a huge advantage. It’s really quick to onboard new employees and it’s very user-friendly. There’s less code to understand and maintain, it updates seamlessly with no downtime, and backups can be used to restore onto a developer’s device to test and debug,” Rüttimann reveals. “A number of other teams at SBB are starting to adopt MongoDB. The team working on the ticket purchasing app is evaluating the technology – with its huge database, its criticality and need for smart search queries, using MongoDB to optimize it could be a big win.”

Jonas Rüttimann, System Architect, SBB