Distributed SQL Summit 2021: How Kroger’s Data Architecture Powers Omnichannel Retail Experiences at Scale
Kroger is America’s largest grocer, with approximately 2,800 stores operating across 35 states. With a mission to Feed the Human SpiritTM, the company’s strategy is to ensure customers can find the fresh food they want—no matter how they want to shop. This strategy requires Kroger to maintain a flexible tech stack. Most importantly, the data architecture must be able to scale to meet growing demand, especially as new experiences are launched.
At Distributed SQL Summit 2021, Sriram Samu, VP of Customer Technology at Kroger, discussed how his company’s data architecture unlocks digital and omnichannel experiences at scale. He provided a rare glimpse into how the business is bringing its data models into a new format. This format is easy to serve at speed, while still being able to integrate with legacy systems.
Kroger is focusing on digital and omnichannel retail growth to serve an increasing number of customers shopping from anywhere. To meet this objective, the company implemented curbside pickup in addition to at-home delivery. The focus on “last mile” fulfillment required Kroger to review its tech stack and operations to keep costs low.
New application services were rolled out to allow customers to notify stores they are on their way to pick up their order. These services track a customer’s parking location and send a final email receipt once the order pickup has been completed. Lastly, Kroger updated its loyalty program, used by over 90% of its customers. This allowed the company to better understand shopping patterns, implement personalization, and deliver an improved shopping experience.
All of these technology integrations and enhancements require Kroger’s technology stack to be very flexible. That also means their databases need to be elastic to meet the growing demands of the business.
Kroger collects a variety of data from across the business, including enterprise, manufacturing, supply chain, in-store, and online. The company uses a variety of databases – such as IMS, DB2 and Oracle – to store and process this data. However, it’s difficult to build new applications and services when there are so many disparate legacy systems in place. As a result, Kroger needed a solution that could bring data into a format that is easy to serve to customers quickly. It also had to be able to integrate with many different systems. This is where YugabyteDB comes into play, an open source, transactional distributed SQL database built for resilience and scale.
According to Samu, the most important part of building an application is understanding the usage patterns and getting the data model right. This means figuring out the use cases and laying out data in the right way to meet the Enterprise’s needs. Many applications do not need ACID database properties when first built – instead, speed is most important. For example, when tracking customer clicks, a business can afford to lose a small number of those clicks. However, they cannot miss any inference data that helps to understand decision-making patterns or lose transactional data. In the long run, Kroger needed a scalable database to elevate customer experience that also had ACID properties.
Another important criterion is finding professionals who, in addition to writing SQL queries, are able to understand all aspects of the database. This is where YugabyteDB’s PostgreSQL compatibility and advanced relational database features proved critical. Kroger was able to move data with ease and without having to retrain teams or rebuild application schemas. YugabyteDB works with popular standard drivers, such as Spring Boot, which allows teams to be at ease when building new applications.
To optimize costs, Kroger has been running its online applications on-prem for more than 30 years, but that solution wasn’t flexible. Samu and his team strategically developed a strong architectural framework before migrating to the cloud. A “lift and shift” approach was just not going to cut it.
Kroger’s move to the cloud is now easy with the new models and architecture built, Samu said. More importantly, a foundation is established to have a hybrid and multi cloud set up. This helped the company scale rapidly and build application enhancements faster while rolling out and managing these enhancements with ease. Kroger also partnered with several cloud providers to run its applications.
PostgreSQL compatibility within Kroger’s new architecture plays a critical role in running its systems on different clouds and choosing the best cloud option. This allows for flexibility and provides standardization so the business can run similar tooling and applications in multiple clouds. Kroger now has all its applications – built the right way – running on Azure, GCP, or on-prem. Integrations continue to play a critical role, and applications do not need to be re-built as a hybrid-multi cloud setup is adopted in the future.
YugabyteDB powers Kroger’s shopping cart application, which runs in the cloud. Search is now running on GCP, and the company is creating many more applications to run on Azure. Kroger is also building some applications on-prem using Kubernetes.
Samu said YugabyteDB has a great engineering team and a wonderful product. And since YugabyteDB is open-source, Kroger would like to start contributing to the community by open sourcing some of the tools it has built. As YugabyteDB is in the company’s data layer, the business would like to innovate in other layers—such as analytics and search capabilities—that can also be powered by distributed SQL. In addition, Kroger wants to revamp internal applications using the underlying data technology used by store associates and category managers, which can help to speed up the process and provide insights when pricing and promotions are planned.
Want to learn more about YugabyteDB in action? Check out all the sessions from Distributed SQL Summit 2021 on-demand, including talks from Fiserv, General Motors, Rakuten, Wipro, and others!