Modernizing the data layer in your stack can be hugely beneficial. But it can also be difficult and, if approached in the wrong way, very high risk.
So how do you do it right? At Cockroach Labs’s Roachfest 2023 conference, Spreedly Senior Software Architect Scott Traver shared three major lessons the B2B payment orchestration company learned when migrating its system from Riak and Postgres to CockroachDB.
Before we get to the lessons, though, here’s how that migration actually looked:
And because Spreedly approached it in the right way, they didn’t just modernize and simplify their data stack. According to Traver, as part of the migration they were also able to:
Remove three custom codebases, two databases, and three protocols
Reduce the total amount of data stored by the system
Enable multi-region localization with high-availability
Enable data retention policy
Enable batch and bulk workloads
And much more!
So how did they do it?
Lesson 1: De-risk the migration by taking it slow
While some companies make database migrations out of necessity, for Spreedly, it was more about being responsible. They wanted to move to modern, scalable data architecture before their existing system hit a bottleneck that impacted their customers. That meant that they were free to approach the migration project cautiously – an approach Traver recommends for reducing risk.
Spreedly adopted what Traver calls a “source of truth” migration strategy. Since they were migrating from a schemaless database to a relational one, they needed to model their data. So they created a side table with keys and type, operating CockroachDB alongside their production setup, which allowed them to separate the migration of data from the activation of the data. This allowed them to move more cautiously, monitoring and easily being able to roll back if issues were discovered without having to take the system offline.
This approach proved fruitful. For example, Spreedly discovered that their application-generated UUIDs had a temporal element to them that would have created in CockroachdDB. Letting CockroachDB auto-generate UUIDs eliminated this issue and improved write performance (since each node can generate its own UUIDs without requiring confirmation from other nodes). And since their application traffic hadn’t yet been migrated from the old system to CockroachDB, this lesson did not come at the cost of experiencing the slower performance first.
Lesson 2: Don’t migrate data you don’t need to migrate
When they decided to migrate, Spreedly’s decision to take things slow didn’t just reduce risk. It also allowed them to take a step back and look at their data holistically. In doing so, they discovered inefficiencies that they realized could be addressed as part of the migration process.
For example, one subset of the data they collect needs to move efficiently through the system but does not need to remain in the primary application database forever. With their old system, the buildup of this no-longer-useful data was unavoidable. CockroachDB’s built-in row-level time-to-live and change data capture features allowed them to pass this data from the database to downstream systems (Kafka) and then subsequently have the data expire via TTL, reducing the clutter of useless data and improving performance.
This would not have been possible if they had not taken the time to review their data systems and evaluate their actual needs. Instead of copying everything over from the old system to the new one, they were able to build a more efficient system.
Lesson 3: Your data is an ecosystem, not a single database
Another important lesson, according to Traver: “CockroachDB does not need to solve all of your problems.”
“One of the things that Spreedly likes most about CockroachDB is what it isn’t,” he says. “Changefeeds admit that CockroachDB may not be the best […] data warehouse or analytics database, but they give you the tools for CockroachDB to be a team player within your business’s larger data ecosystem. That was really key to finishing this migration in a successful way.”
In other words: when you’re migrating, find the right tools for the job and make sure that they will play nicely with each other and any future tools you might want to integrate, rather than trying to find a single tool that does everything.
Watch the full talk to get more of Spreedly’s migration insights:
