How Shopmonkey Built a Geo-Aware Auto Care Platform

How Shopmonkey Built a Geo-Aware Auto Care Platform
[ Blog ]

You deserve zero downtime

Resilience and high availability, meet online schema changes and live database updates -- no planned downtime required.

Learn how to do a live schema change


More than nine out of ten US households (91.7%) own at least one automotive vehicle. Whenever you take your personal chariot in for an oil change, go online to schedule a repair with your local garage, or do pretty much any other automotive upkeep, you’ll very likely also encounter Shopmonkey — at least behind the scenes. Over 6,000 automotive retail locations in the US and Canada rely on Shopmonkey’s platform for operating every part of their businesses, from point of sale and customer communication to parts procurement and inventory management.

“We like to think of ourselves as the operating system for the entire retail automotive repair industry,” says Jeff Haynie, Shopmonkey’s Chief Technology Officer. “And we’re growing really fast, adding about 200 to 300 new locations every single month.” Rapid growth is the right kind of problem to have, but Shopmonkey’s success was straining their technical infrastructure, causing issues with data consistency and scaling. The only thing that might slow the company’s future growth was the platform’s own technical debt. 

At this year’s annual RoachFest user conference, Haynie explained how Shopmonkey re-architected their monolithic application to provide localized, fast, and highly available access to the platform from thousands of physical auto shop locations throughout North America.

Getting physical with user locality

Shopmonkey had a very unusual challenge to solve: Each of their users is tied to a unique physical location. With 350,000 automotive repair businesses as potential customers spread across the US and Canada, that is a lot of ground to cover. Their new architecture would need to allow strategic, even hyperlocal, geographic data location. And their new database would need to make this straightforward to implement, update, and scale — while providing rock-solid reliability.

“We realized that we had to rethink our entire architecture, and that fundamentally started with the database,” Haynie explains.

“CRDB was the only database out there we’ve been able to find that allows us to provide a geo-aware database in a highly scalable manner,” says Haynie. “But it does require you to think differently. It’s not a Postgres database just running geo-distributed. It’s a fundamentally different way to think about your database design, your schema, your tooling, how requests are routed, et cetera.” This meant Shopmonkey’s developers needed to learn to think in new ways around, for example, planning and indexing queries. Ultimately, though, retraining their developers to a distributed mindset was not difficult, and also increased their ability to harness the full benefits of their new database.

From Mongo to multi-region

For a deep technical walkthrough of their ultimate architecture redesign and migration, be sure to watch Shopmonkey’s presentation at RoachFest ‘23. The slide deck with diagrams and reference architecture is also available, along with a transcript.

Shopmonkey chose to use CockroachDB as a managed DBaaS as the foundation for their fully-rearchitected application. They now run CRDB in three super regions with nine total nodes, with each shop assigned to a specific region based on its physical location, which allows for load distribution and easy data movement. The team can also shift load between regions during outages or for capacity constraints. 

Regional consistency is crucial, so they use CockroachDB’s features to ensure data is routed correctly. They utilize Google Geo load balancers and JWT authentication tokens with region IDs to route requests to the closest region. 

To meet their unique “widespread location of physical users” challenge, Shopmonkey has built additional tools and infrastructure to work with CockroachDB, including a custom connection pooler, telemetry and tracing systems, and a change feed infrastructure. The team also developed a custom online migration tool called Wrench to apply schema changes quickly and efficiently. It wasn’t all custom work, though. For example, tracing and logging are crucial for troubleshooting in their distributed system, and the team quickly integrated CockroachDB’s fingerprinting feature into their own code for easier debugging. 

However, Haynie says, the team often utilizes custom tooling to meet Shopmonkey’s unusual and highly specific business needs. Business-differentiating features and functionality that the team can focus on exclusively, he adds, because using CockroachDB as a managed service takes away database operations and maintenance. Whenever issues arise, there is a dedicated support team to help Shopmonkey diagnose, fix, and even optimize the situation.

“From our perspective, it provides huge opportunities that traditional databases just can’t provide. Migrating to CockroachDB has been a huge, huge success for us and we’re really excited to be partnered with Cockroach.”

About the author

Michelle Gienow github link linkedin link

Michelle Gienow is a recovering journalist turned front end developer based in Baltimore, MD. She creates content around her central obsessions: Jamstack, distributed architecture and developing a cloud native mindset.

Keep Reading

> ALTER DATABASE FortiSASE SURVIVE REGION FAILURE: Migrating to CockroachDB

Specializing in the convergence of networking and security, Fortinet is a leader in the cybersecurity industry. Fortinet …

Read more
Santander: Hacking human error to achieve operational resilience

If there is one inevitable truth in technology, it is that disasters happen. Calamities like fires, climate …

Read more
CockroachDB on Azure, multi-region serverless SQL, and more announced at RoachFest '23

Each October, RoachFest gathers together application owners, architects, engineers, and operators running their …

Read more