Reinventing OTTO: From retailer to marketplace

For decades, OTTO has been a trusted name in European retail, connecting millions of customers with carefully curated products. But times were changing. E-Commerce was evolving, and competitors were turning their platforms into vast, dynamic marketplaces. OTTO saw the writing on the wall: it was time to reimagine its business.

The vision was bold. OTTO would empower thousands of external partners to sell directly to its customers, expanding it’s catalog from millions to tens of millions of products. The transformation promised not only growth but also a stronger foothold in a highly competitive market.

Competitors weren’t slowing down. If OTTO wanted to compete, it needed a modern, scalable solution - and it needed it fast.

But ambition came with complexity. As partners surged from 500 to over 6,500 and the number of product variations ballooned from 2 million to more than 33 million, the cracks in OTTO’s legacy system became impossible to ignore. Daily updates - price changes, stock adjustments, and new listings - poured in by the millions, demanding near-instant processing.

“Our old system couldn’t keep up,” said Jürgen Holtschmidt, OTTO’s Head of Technical Product Development Platform Data. “Partners expect updates in real time, and we just weren’t equipped to handle the load.”

Otto’s legacy system, built on a monolithic architecture, was a relic of a simpler time. It had been designed for the needs of a traditional retailer, not a bustling marketplace. As the business grew, so did the strain on its infrastructure.

The technical issues were clear:

1. Scalability Bottlenecks:
   The monolithic architecture relied on a single relational database to process all operations, from handling incoming product updates to responding to partner queries. This synchronous design created a central bottleneck, particularly during traffic spikes. Partner growth and increasing data volumes only exacerbated the problem, forcing Otto to consider hardware-heavy fixes that were neither cost-effective nor future-proof.

“In the ancient system, all the requests and incoming data were processed synchronously,” Markus Hahn, Senior Software Developer at Otto explained. “It was already a bottleneck when traffic increased a little, so scaling with more partners and products wasn’t possible.”

1. Delayed Data Processing:
   Millions of daily updates strained the system's ability to process changes in real time. Updating critical product details—such as pricing and availability—needed to be instantaneous. Delays would leave partners frustrated and uncompetitive, as e-commerce thrives on speed and accuracy.

“If a partner sends us a price update, they expect it to be live in 15 to 30 minutes,” Jürgen noted. “Anything longer puts them at a disadvantage.”

1. Maintenance Costs:
   Scaling the legacy system came with a hefty price tag. Each traffic surge required expensive hardware upgrades to keep the monolithic architecture running. These investments added up quickly, providing only temporary relief while failing to address the underlying limitations of the system.

“Scaling with hardware wasn’t sustainable,” Markus said. “We had to keep investing more, but the architecture itself couldn’t handle the growing demands.”

1. Complexity:
   The monolithic design also made operations increasingly complex. Manual interventions were often required to resolve bottlenecks and system errors, consuming engineering resources that could’ve been dedicated to innovation. Debugging and deploying updates became cumbersome, further slowing progress as the system grew.

“In the old system, everything was so tightly coupled,” Markus explained. “Even a small update required careful coordination across all components.”

“Scalability and performance were critical for us,” explained Markus Klubmann, a senior developer at Otto. “Our monolithic system simply couldn’t process the massive volumes of data we were dealing with. We needed a completely new approach—something flexible, resilient, and built for growth.”

To solve its challenges, Otto decided to rebuild its system from scratch. The team turned to Axon Framework, a solution designed for modern, event-driven architectures that prioritize flexibility and scalability.

The transformation centered around three core strategies:

1. Command Query Responsibility Separation (CQRS):
   Separating read and write operations allowed Otto to scale these functions independently. Writes (e.g., updates from partners) were processed asynchronously without affecting reads (e.g., customer queries). This separation eliminated many of the bottlenecks caused by the legacy system’s synchronous design.
   
   “CQRS let us scale our operations in ways the monolith couldn’t. It decoupled our processes, making them both faster and more reliable,” Markus said.
   
   
2. Event Sourcing:
   By storing all system changes as events, Otto gained the ability to replay data when debugging issues or recovering from errors. This event log also allowed them to eliminate reliance on external partners for resending data during system failures.
   However, event sourcing came with its own challenges. Managing a rapidly growing event store required Otto to design compact, efficient events and optimize how they stored and queried historical data.
   
   “Event sourcing was a powerful addition, but we learned early on that careful design was critical,” Markus noted. “Our team spent a lot of time ensuring we didn’t introduce unnecessary complexity.”
   
   
3. Microservices Architecture:
   Moving away from the monolith, Otto adopted a microservices approach, breaking its system into smaller, modular components. Each service was designed to handle specific tasks, such as processing product updates or managing partner onboarding, making the platform easier to adapt, scale, and maintain.
   
   This approach worked seamlessly with CQRS and event sourcing, which enabled the decoupling of read and write operations and the storage of historical events. Together, these patterns ensured each microservice could operate independently, replay data as needed, and handle massive traffic without bottlenecks.
   

AxonIQ wasn’t just a vendor—it was a partner in Otto’s transformation. The AxonIQ team provided workshops, technical guidance, and ongoing support to help Otto’s developers implement CQRS and event sourcing effectively.

“The collaboration with AxonIQ was outstanding,” Jürgen said. “Their technical expertise and flexibility helped us navigate obstacles and build a system that truly works for us.”

This partnership ensured Otto could fully leverage Axon Framework’s capabilities, laying a strong foundation for long-term success.

With its marketplace thriving, Otto is now focusing on optimizing for future growth:

• Streamlining Event Storage:
  Exploring state-stored aggregates and refining event storage strategies to manage growing data volumes more efficiently.
• Optimizing Product Offerings:
  Balancing variety with relevance to create a superior customer experience.
• Scaling Smarter:
  Building on its scalable architecture to handle even greater demands as the business evolves.

“This architecture gives us the flexibility to adapt to whatever comes next,” Markus said. “We’re confident it will support our continued success.”

Otto’s journey from retailer to marketplace is a testament to the power of modern architecture and strong partnerships. By adopting Axon Framework and event-driven principles, Otto created a scalable, reliable platform capable of meeting the demands of a rapidly changing market.