DriveCentric Builds Next-Generation Architecture for CRM with Confluent

As automotive dealerships navigate changes in consumer demand and a shift to remote sales due to the pandemic, the need for communication tools that enable effective customer engagement across all channels is becoming more acute. In an environment in which digital experiences are becoming more important than showroom experiences, DriveCentric meets this need with CRM technology that makes it easier for dealers to boost engagement, shorten sales cycles, and spur growth.

DriveCentric has a unique position in the market that has led to substantial growth recently. To meet the increased demand and its customers’ evolving needs, DriveCentric is transitioning its core product from a traditional multilayered web application oriented around data at rest to a more scalable microservices-based architecture oriented around data in motion with Confluent. As a fully managed cloud service, Confluent meets the stringent requirements of DriveCentric for reliability and security, while enabling DriveCentric teams to spend their time delivering value-added capabilities instead of managing infrastructure.

“As our customer base continues to grow quickly, we need the ability to scale at a rapid rate which led us to microservices,” says Chris Burriss, chief technology officer at DriveCentric. “Confluent is the glue that holds those microservices together and enables them to communicate with each other. In addition to providing the performance, scalability, and resiliency that we require for this critical piece of our architecture, Confluent provides the expertise and operational support that lets us focus on building features that are going to help our customers sell more vehicles.”

DriveCentric is moving toward using Confluent as a central nervous system that connects microservices across the company and with automotive dealership applications. “Our customers tend to use several different automotive-specific products, and they need all of those products to be able to communicate with each other,” says Burriss. “And Confluent plays a vital role. As we build new integrations and rethink how we scale our old integrations, being able to publish events into a cohesive model for our CRM platform makes a huge difference.”

Business Results

Scalability for ongoing growth ensured. “In our production environment, we need solutions with a proven track record of high scalability and resiliency,” says Burriss. “With Confluent and microservices, we are better able to scale. The Confluent team has been great at ensuring our environment is appropriately sized for our current needs. We also see the growth potential over time as more of our features become reliant on event-driven microservices.”

Peak workloads handled seamlessly. “The number of messages our platform handles can vary from day to day, but no matter how many we process, Confluent has never been a bottleneck,” says Burriss. “When we make changes to our text search capabilities, for example, we need to rehydrate AWS Elasticsearch with data from our core system. We use Confluent as the backbone for that process, and it easily handles millions of messages.”

Focus on delivering value maintained. “The more time we can spend on solving business problems for our users— instead of worrying about infrastructure or maintaining on-premises servers—the better off we are,” says Burriss. “We let the Confluent experts focus on keeping our Kafka implementation up and running well, so we can focus on growing the business. To my knowledge, we’ve never had any downtime related to Confluent.”

Development and production support simplified. “The Confluent Cloud interface provides the core capabilities we need from a development and production support standpoint,” says Burriss. “Kafka can be a complex technology, but Confluent simplifies the critical parts of Kafka that developers really care about and interact with day to day, such as managing topics, viewing consumer groups, monitoring consumer lag, and troubleshooting issues.”

Technical Solution

DriveCentric is transitioning from its legacy architecture with a phased approach in which teams replace functionality in the core system with new microservices. Using this strangler pattern, DriveCentric chose a clearly defined, relatively low-risk feature for its initial event streaming implementation. The feature—generating a recent customer list—was implemented by publishing customer access events from the core application to a new microservice that consumes the events and generates this list.

“We picked a feature that was small and fairly safe. If it were to go down in a production setting, it wouldn’t be a showstopper,” says Burriss. “We built a new microservice following our development standards, and we hooked it into Confluent in our production environment on AWS. With that first step, we could start monitoring how it was consuming and begin making adjustments as we learned more.”

To jumpstart development, DriveCentric took advantage of support and resources provided by Confluent, including the Kafka.NET Client. “Confluent worked with us on some demos and technical Q&As as we were getting started,” says Burriss. “And, as a .NET shop, we were able to use the .NET library that Confluent provides to get up and running quickly.” Building upon the success of this first microservice, DriveCentric has since built and deployed several more, all of which have contributed to improving the customer experience. “Virtually everything that we have running through Confluent is visible to the user through the web UI or mobile clients in some form,” says Burriss. As new microservices come online, more DriveCentric data is in motion, with substantial increases in the amount of data flowing to the services from the core application and flowing from them back to the core application. “Because the new microservices process a much higher volume of data than our first one, we’ve seen more than a tenfold increase in message volume,” says Burriss. “And, Confluent is in the middle handling it all with no issues.” By setting up consumer groups—sets of consumers that cooperate to consume data from specific topics— DriveCentric is able to share the workload among multiple consumers, adding more as needed. “The consumer group concept is really useful to us,” says Burriss. “We can spin up multiple Amazon ECS tasks and have them all working in parallel without having to worry about duplicate processing of events.”

The microservices-oriented architecture has also helped DriveCentric teams work in parallel, which is an essential part of its growth. Each team can develop its microservice without interfering with other teams. “When you start adding development team upon development team, you have to make sure that everyone can be productive and work on features without overlapping with each other, creating code conflicts and other inefficiencies,” says Burriss. “Our new architecture makes that possible because there is a clear separation—as long as they know what message schema to use, a team can move forward without worrying about the other teams.” As DriveCentric continues its journey, development teams are exploring the use of ksqlDB for stream processing and built-in connectors to streamline further integrations. In the meantime, the company is building experience and momentum as it continues to transition its core platform to the new microservices-oriented architecture with Confluent.

Learn More About DriveCentric