The problem with rigid schemas in specialty insurance
The driving force behind Price Forbes’ move to MongoDB Atlas was a project to build a Compare-the-Market-style quote-and-bind system.
In the world of specialty insurance, Price Forbes deals with incredibly niche areas. When a broker enters details about a risk, they might be dealing with construction, cargo, aviation, or even outer space. From a technical standpoint, it’s a polymorphic nightmare.
“While every product has a top-level identity, each has its own unique set of fields and properties,” said Meyer. “When we looked at our existing MySQL implementation, we realized we were facing a series of impossible trade-offs. We could use attribute tables that are slow to query, we could use a single massive table with thousands of mostly empty columns for every possible product field, or we could create a different table for every single product.”
None of these SQL-based options were sustainable for a fast-growing business. Price Forbes needed a solution that allowed users to simply throw a product into the database and have it stored in a single collection while remaining fully searchable.
MongoDB’s JavaScript Object Notation (JSON) model was the natural fit. It allowed Price Forbes to identify each product by a class so that when it was retrieved, it was automatically deserialized into the correct format for the application.
Doubling performance: Moving from Cosmos DB to MongoDB Atlas
Price Forbes’ journey didn't lead straight to MongoDB Atlas; it started with a MongoDB-compatible instance of Cosmos DB on Azure. It worked as a proof of concept, but Price Forbes quickly hit a ceiling: Cosmos DB was using an outdated version of MongoDB, which limited document size and prevented Price Forbes from using the latest aggregation frameworks. It also turned out to be quite slow, leading to increased complaints.
“So we engaged directly with MongoDB and ran another proof of concept,” said Neagu. “The results were staggering: our performance more than doubled.”
The migration process itself, supported by MongoDB Professional Services, was incredibly smooth. Price Forbes was given five days of professional service time, but it only took two days to write the migration scripts and migrate all data remotely. The team didn’t encounter a single issue with any data type; it was a completely painless experience.
Powering the Placement Hub with reactive code
The most significant success of Price Forbes’ MongoDB adoption has been the Placement Hub. This is a next-generation platform that enables brokers to acquire risk information, process it into policy administration systems, and access vital documentation.
A key reason why this platform is so fast is that Price Forbes decided to use reactive code. In a standard, non-blocking model, a server thread handles a request and remains occupied until it completes. This can bog down the system when handling thousands of requests.
“We use the analogy of walking 10 dogs,” said Neagu. “In a non-reactive model, you throw a ball and wait for the first dog to return it before throwing the next. In a reactive model, you throw all 10 balls in quick succession; the ‘threads’ are released to do other work while the ‘dogs’ are busy fetching the data.”
Because MongoDB Atlas has drivers specifically designed for reactive programming, Price Forbes’ application is lightning-fast. It’s achieved a 90% adoption rate for the Placement Hub—a rate that’s unheard of in the insurance industry.