Presented by MongoDB

Founded in New York City in 2009, Rent the Runway is disrupting the trillion-dollar fashion industry and inspiring women with its vision for a more joyful, financially savvy, and sustainable way to feel their best every day. Through Rent the Runway, customers can rent, buy, or subscribe to designer apparel, accessories, and home decor from over 750 brand partners. While Rent the Runway aims for a seamless process for its customers, the back-end technology powering this one-of-a-kind logistics operation is complex.

The company has two distribution facilities — one in New Jersey and one in Texas — that receive, clean, and repair items before swiftly packing and shipping them out again. This involves a significant investment in AI, radio ID tags, and robots to more efficiently sort, clean, and ship the garments.

Ahead of his presentation at MongoDB’s annual developer conference, Rent the Runway’s Director of Engineering, Mike Liberant, discussed the company’s data strategy and code-first approach and how that factors into the company’s end-user experience.

MongoDB: Can you describe what goes on behind-the-scenes at your distribution facilities when a garment is returned by a customer?

ML: First, every garment returned to our warehouses must be cleaned and sorted before it’s available to rent again, so our goal is to automate the movement of goods where possible to streamline this process.

Worn garments are first ushered onto a conveyor belt before they go through an X-ray machine. Why an X-ray machine? Quite frequently, our members will accidentally leave items in the pockets of their rented garments (lipstick is a frequent offender) that we need to catch before they go into a washing machine.

After it passes through the X-ray — hopefully makeup-free — our software sorts items into one of 20+ different bins for cleaning. Adding to the challenge is the fact that these garments require different cleaning methods, meaning that the robotic arms managing the sorting process have to understand which bins correlate to which cleaning method. These solutions are important to scaling our operations, and success comes down to equipping our development teams with tools that help them make sense of the massive amounts of data generated.

MongoDB: How does this massive amount of data impact your development teams and data model?

ML: Given our tight timeline, using a relational database was a no-go due to the upfront requirements you need to account for in terms of designing schema properly and the corresponding data model. We knew there would be a large learning curve and we would have to consistently iterate on that data model, which entails changing your schema for every iteration when using a relational database.

This means a database administrator has to coordinate with a development team to add columns in, and the developers then have to go back and update their code to match the corresponding data. It’s a unique challenge for our engineers because we’re working with a variety of different garments and we’re trying to build software that can clean them correctly.

MongoDB: How did your database choice impact the overall outcome?

ML: Using MongoDB’s document data model was key to reducing our developers’ cognitive loads. It doesn’t require the upfront work of designing our schemas and it allows us to stick to a code-first approach.

As object oriented software developers, we can conceptualize the world around us as objects easily. For example, a car is an object with certain attributes and a garment is an object with certain attributes. When that garment has a specific cleaning method attached to it, it’s just another attribute. The document model allows us to deploy, go live, and add attributes later on with very little coordination between database administrators. This means our developers write code exactly how it appears in their heads, instead of having to normalize the data into multiple tables.

MongoDB: Does this data strategy stretch across the company?

ML: Since joining Rent the Runway in 2019, I have focused on defining our North Star vision for building applications, including how we architect our systems. We have been able to separate each business domain using microservices backended by MongoDB Atlas, Kotlin, and Spring Boot, to provide a modern tech stack.

During the pandemic, we focused on increasing efficiency through enhanced automation while inbound and outbound volume was lower. Minimizing our inbound processing time is not only good for our business, it helps us free up inventory faster so our customers can rent or buy it. When a garment is picked up by a robotic arm, the arm scans the garment’s RFID tag and determines what bin it needs to be sorted into. The robotic arm also tells us when a bin is full and needs to be moved to a washing machine, when it’s empty and all these other sorts of data points that are useful. Anything data-related also gets copied to our data warehousing system.

Any downtime in our warehouse creates a delay for our customers, so we proactively took measures to de-risk this by implementing triggers — which enable us to execute application and database logic automatically — either in response to events or on a predefined schedule. Using Realm Triggers within Atlas to pipe data to our data warehouse is essentially a no-code solution that helped to further de-risk our entire system, allowing us to extract the value of this data for future forecasting of warehouse workloads.

MongoDB: What were the benefits of using a multi-cloud database service?

ML: Using Atlas, we reached our time to market for the warehouse automation rollout in half the time of our legacy tech stack. We achieved this purely through this code-first, dynamic data modeling approach and were able to improve the efficiency of our inbound sortation dramatically. At the end of the day, this plays a key role in improving inventory availability and, therefore, creating a superior customer experience.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. Content produced by our editorial team is never influenced by advertisers or sponsors in any way. For more information, contact