“YugabyteDB Managed” is now called “YugabyteDB Aeon”. To find out more, visit our launch blog.

Leading Omnichannel Retailer Improves Their Digital Customer Experience with YugabyteDB

Part of the Fireside Chat Series

January 3, 2023

A leading US-based omnichannel retailer that sells a wide variety of home, baby, beauty, and wellness merchandise through their physical stores and eCommerce sites is actively working to optimize and modernize its digital platforms to better support its customer-centric culture.

Their goal is to find new and better ways to engage with customers while keeping their IT architecture simple, resilient, and able to perform at scale.

We recently sat down with their Director of Digital Engineering and Architecture to chat about their database modernization journey, including why distributed SQL made sense. He also shared insight into how they evaluated and tested YugabyteDB, as well as their “aha” moments.

Below is an excerpt of the key points covered during the conversation.

Q: Like many industries, retail is going through tremendous changes. Retailers are transforming to meet high customer expectations. How have you and your team approached that transformation? What are some of the technologies that have been important to your transformation?

I‘ve seen our e-commerce platform go through several digital transformations. In 2013 we moved from an old ASP.net application to the Oracle ATG Commerce platform. Then in 2018, we moved to a headless architecture. We also revamped our front end to a React-based application. Then along the way, we moved to progressive web apps, and now we are adopting the idea of Micro Frontends.

Also, in 2018, we began modernizing our digital platforms by migrating services to cloud-based Spring Boot microservices deployed with Kubernetes, using databases like Firestore, Cloud SQL, Cassandra, and Redis.

Today, we are in the process of modernizing our core e-commerce platform, including workloads such as promotions engine, catalog, customer accounts, registries, and card and checkout to a cloud-based microservices architecture. We chose YugabyteDB as the database for all these workloads. By the end of this current modernization effort, we expect to have faster website and mobile app performance and will be able to show the most updated data—like price and product availability/inventory—to our customers. In addition, we will be able to run campaigns quickly and have more resilient services. We also think we should save a lot in terms of operating costs.

Q: What role does your database play, and how has that changed as new services have come on board? Have you had to rethink what you do with a database?

The database plays a very important role, especially as we move from a monolithic to a microservices-based architecture. Monolithic applications have monolithic databases. Every component of the application shares the data. This may sound good, but it also creates tight coupling. This tight coupling means we cannot deploy any changes independently, so time to market increases. To scale, we have to scale the entire monolithic database. Performance is also challenging because, with a shared database, we have to create extremely large tables and an extremely large number of joins on these tables.

As we modernize our monolithic applications to microservices, we must also split that database. For example, some services may require a relational database, but some may perform better with NoSQL. Some might need an in-memory database. By splitting databases, we can scale easily, deploy changes quickly, and target to improve the performance of individual services.

Q: With a monolithic database, scale can only go one way—vertically. Therefore, you’re forced to look for bigger, more powerful servers, and—at some point—you find yourself buying proprietary, finely-tuned, customized, and expensive hardware. Commodity hardware won’t work. Doors (cloud, IaaS, etc.) are closed to you because you cannot connect standard servers. You’re locked into a more customized system. Would you agree with that?

Yes. Absolutely. There are some practical limitations when trying to maintain a monolithic database, and a big one is hardware. This is where a distributed database becomes very appealing. You can create a cluster of cheaper compute machines in the cloud and then create a logical database using those clusters. Scaling is easy. For example, it’s pretty easy to scale memory, scale the processing cores of those compute machines, or even add nodes.

Q: What are some of your key application workloads? Are they different from what they were maybe five years ago?

The e-commerce space is evolving. Customers interact with us differently than they did three or four years ago. So our applications and workloads have had to evolve. For example, accurate product inventory is now essential for a good customer experience. Performance is another area where customer expectations have changed.

To perform well, they all have different requirements. Some demand strong consistency when we have to, for example, show accurate or up-to-date product inventory. But for other workloads, like profile services where the customer sessions are pinned to a region, being eventually consistent is OK. It’s acceptable if updates are available to other regions in a few seconds.

Other services, such as our cart and checkout operations, require support for a high number of reads and writes. However, services, like our promotions engine which has few updates, only need support for a high number of reads.

Q: After you went through your overall evaluation of databases and workloads, you listed out and prioritized your requirements. What were your requirements for your database?

Our #1 requirement was performance at scale. We required a database that could scale horizontally, which distributed databases can do. But they also needed to have the lowest possible latency required for an ecommerce application.

The database also needed to be highly available, geographically distributed and redundant—able to survive a node or even a full region outage with little to no data loss.

Other requirements for the database were to be ACID compliant along with supporting PostgreSQL, recursive CTE queries, multiple schemas, etc.

Q: Based on those requirements, I understand that YugabyteDB was one of the databases you looked at. There were a couple of others as well. Is that correct?

That’s right. We shortlisted two other databases besides YugabyteDB. We then evaluated all three based on ease of maintenance and resiliency. We also ran a few performance tests before we made our selection.

Q: Once you had that shortlist, you ran some tests to see which would best serve your needs. So could you walk us through your testing process? What were some key steps, and what did you look at specifically?

First, we did a basic test using your fully managed DBaaS, YugabyteDB Managed, to spin up the database to test how quickly it could be done. Then, with the help of the Yugabyte team, we did a resiliency test where, on one side, we ran a script that loaded records to a table. On the other side, we brought down a node from the cluster. The other nodes took over fairly quickly.

Then we installed the YugabyteDB database on our virtual private cloud (VPC), where we ran performance benchmark tests with our ecommerce platform. This was not a full-blown holiday stress test, but we got fairly good response times compared to the other databases.

We did a few more POCs, such as loading bulk data through copy and loader commands. We loaded five to eight million records in just a few minutes. Finally, we did another POC where we connected our services to YSQL—Yugabyte’s SQL interfaces —to see how it performs.

Q: You mentioned YugabyteDB Managed; that’s our fully managed database-as-a-service offering. We also have YugabyteDB Anywhere, the self-managed version of our database that you can install in your own data center. You were able to leverage the cloud for some of the early testing, and I assume that helped you accelerate some of those initial tests. Is that true?

Yes, that’s true. We did the basic evaluations with YugabyteDB Managed. We did failover testing and some parts of the performance testing on it as well. But we quickly moved over to the self-managed offering (YugabyteDB Anywhere) because that’s where we wanted to pivot.

Q: As you were going through these tests, were there any “aha” moments? Again, distributed SQL is a new approach, so did any moments stand out where you might have said, “Oh, wow, this is different,” or “This can help us.”?

Yes, there were several. The first came when we realized that with YugabyteDB we could have both SQL and NoSQL interfaces, which made our setup for the evaluation pretty easy. Then during failover testing, we saw how quickly (within a few seconds) the peer nodes were able to detect the failure of the master leader node. The peers selected the new master leader themselves.

Our final “aha” moment came during performance testing, where we achieved a less than five millisecond response time, on average, for one of our card-related operations. That was pretty awesome.

Q: As you scaled out, you could meet your performance-at-scale requirements because you were able to maintain that low latency regardless of how much you grew the system. Is that correct?

That’s right.

Q: Perfect. As a last topic, let’s chat about the organizational side of this process. How have your teams evolved as you’ve evolved your database strategy and journey?

Any change to a production environment is a big event, and database changes are even more difficult. However, by modernizing, we now have lean teams that can make changes faster and independently. All services are loosely coupled, so if one team wants to go live before another, they can easily do that. They can deploy faster. We’ve moved from monthly deployments to two times a month to weekly. Our goal is to deploy a change to production whenever that change is ready—anytime.

Discover More Customer Fireside Chats

Read more great customer stories from Yugabyte:

How a Modern Data Layer Powers Omnichannel Success

Data-Driven Success. How YugabyteDB Powers Retail Omnichannel Growth - ebook thumbnail Master omnichannel success with YugabyteDB, and discover how top retailers optimize operations, diversify channels, and elevate customer experiences.