MongoDB Supports Swiss Post in Sorting up to a Million Parcels Each Day

THE CHALLENGE

Using MongoDB Atlas to support efficient parcel delivery for Swiss Post

Across Europe, the parcel business has doubled in the past 10 years. Swiss Post, Switzerland’s national postal service, sorts and delivers a million parcels daily and needs to retain market share against a host of new, specialist parcel delivery services. Besides the sheer volume, the need to bill, weigh, and sort each item according to its sender, recipient, destination, and other information adds layers of complexity. The responsibility for supporting this 24/7 operation is considerable.

“If parcel sorting doesn't work, the system gets congested, the trucks can’t unload, and things get out of hand very, very quickly,” said Meinrad Jean-Richard, Software Architect within the logistics services department at Swiss Post.

The organization has 13 parcel sorting centers across Switzerland. Logistics is key to a smooth operation. Jean-Richard and his colleague, David Riedo, DevOps Engineer at Swiss Post, are charged with rebuilding and modernizing the software infrastructure needed to support parcel sorting for the entire enterprise. Swiss Post had favored a decentralized software infrastructure, reliant on a relational database SQL server, however it became clear this approach was unsustainable. It needed manual overwork, incurred high operating and maintenance costs, and was prone to error—an additional expense. Inevitably, this led to caution over making new software releases. Swiss Post was limited to just four releases a year, having to spend excessive time in manual testing.

“With the DevOps approach, it’s us—the developers—operating those critical systems. If something goes wrong and the trucks can't unload, we get woken up at night,” explained Riedo. “That’s a huge motivation to deliver good software.”

Swiss Post requires a modern infrastructure that would enable the more frequent release of error-free software. Given the volume of data the development team was dealing with, and the need for fast lookups of all the data aggregated on any single parcel, it favored a NoSQL document database that it could adapt to specific needs. The understanding was that this would make it easier to onboard new centers, reduce the workload on the ground, and accelerate the time to market for new software updates. In short, everything needed to ensure parcel processing centers could operate with Swiss efficiency.

OUR SOLUTION

Enhancing performance for instant retrieval and response

The initial approach was to pilot an imitation document database that claimed to be compatible with MongoDB's API. However, there were soon issues—progress was slow, the product had a limited feature set, and, unlike MongoDB, there was no Docker image, which the team relied upon for automated testing. With the MongoDB C# driver used as the interface to the imitation database, and being dependent on MongoDB’s Docker image, a full switch to MongoDB seemed a natural choice.

“We already had the baseline, and the tooling we started with was set to MongoDB,” said Riedo. “The change was seamless.”

For the development team in the logistics department, performance is everything. Documents need to be found quickly, and search response times must be immediate.

The data generated by a million parcels a day is categorized into two main types: events and master data. The former includes all parcel-related activities, from the initial request to delivery progress, including successful or missed deliveries and alternative pick-up options. The latter includes globally applicable information such as addresses, postcodes, and delivery zones, the essential components for successful parcel sorting. Both are now stored in MongoDB.

To efficiently manage parcel information, Swiss Post now stores all data related to a piece of mail in a single document, using MongoDB's flexible schema collections. This approach allows Swiss Post to quickly process and route parcels on sorting machines. The MongoDB time-to-live index automatically deletes old mail pieces after 30 days, streamlining data management without manual cleanup.

To aid diagnostics and recovery, Swiss Post takes regular snapshots of master data, helping identify the state of data and allowing a rollback to previous versions if current data is corrupt. To manage this efficiently, the team uses partitioning in MongoDB, which supports seamless data updates without impacting performance. Snapshots are published on Kafka, consumed, and then switched to new collections, with old ones periodically cleaned up.

“MongoDB Atlas plays a crucial role here,” said Jean-Richard. “We rely on it to access our clusters and build the next generation of software solutions.”

OUTCOME

Continuous integration and deployment enable quicker time to market

The adoption of MongoDB has helped transform Swiss Post operations. Rather than four major software releases a year, a DevOps approach sees up to six releases a day and creates a cadence of continuous improvement. Database responsiveness is up by 67%. Riedo and Jean-Richard say this leap in productivity has been made while reducing development costs.

Pipelines and testing are fully automated, with 100% coverage of every line of code on different levels of testing.

“This change has enabled us to reduce the time to market to levels we couldn’t get near with the old system,” said Riedo. “We’re currently deploying roughly 300 times more per year.”

The ability of MongoDB to scale quickly has helped accelerate the modernization of sorting center operations. The team needed to load considerable data from Kafka as each sorting center was integrated. “We were able, for a very short time, to scale up our cluster to support the migration,” said Riedo. “And then for the normal load, we could scale it down again to the level it will remain. We greatly appreciated that flexibility.” “Now, adding a new sorting center doesn’t worry me. I know we can scale our services and scale up MongoDB.”

The aim is to have all sorting centers running on MongoDB within a year. MongoDB’s performance and analysis tools enabled the team to identify slow queries and missing indexes, something they feel other solutions might not have revealed. As a result, performance bottlenecks are rare and easily fixed. For Jean-Richard, predictability has been a key benefit: “It's clear how MongoDB is going to behave. There are no random events, no sudden slowing down. We can rely on it.”

For example, when using a relational database, it was a daily occurrence to experience slow queries with no one knowing the reason. “You just had to live with it, and hope for the best,” he added. “These types of things don’t happen with MongoDB Atlas. You know what to expect.”