From Monolith to Microservices: How Otto Became a Marketplace

Introduction

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 its 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 like Amazon 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 7,000 and product listings ballooned from 2 million to 60 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.

The Challenge: Outgrowing the Legacy System

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.”

2. 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.”

3. 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.”

The Solution: Monolith to Event-Driven Microservices Migration

To solve its challenges, Otto decided to rebuild its system from scratch. Otto's team chose Axon Framework to build an event-driven architecture that put flexibility and scalability first.

The transformation centered around three core strategies:

1. Command Query Responsibility Segregation (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

   To get from monolith to microservices, Otto broke 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.

   “Axon Framework was the right fit,” Markus shared. “It provided the tools we needed to implement domain-driven design and handle the scale and complexity of a modern marketplace.”

A Full Record of What Happened and Why

Unlike traditional logs, which capture fragments, Otto’s event stream preserves full causality; critical for audits, debugging, and now, AI oversight. When decisions need to be explained, not just reported, this structure makes it easy.

Otto didn’t just switch to event sourcing to fix failures. They ended up with something more powerful:  a complete, queryable system of record for every marketplace decision. That means they don’t just know what changed, but why it changed, under what conditions, and what else it impacted.

Technical Impact: Stability and Scale

Otto's new system addressed every pain point the legacy system had struggled with:

Effortless Scalability

Otto scaled to 7,000 partners and 60 million products, processing millions of daily updates with ease. Horizontal scaling ensured the platform could grow without requiring expensive hardware upgrades.

High Availability and Stability

The system maintained near-perfect uptime over four years, ensuring uninterrupted service for partners. Even during peak traffic, operations ran smoothly, thanks to the decoupled CQRS architecture.

Improved Data Flow

Real-time processing of partner updates ensured price and stock changes were reflected on the platform within minutes, keeping partners competitive and customers informed.

Efficient Maintenance

The modular design of the microservices architecture reduced maintenance costs and allowed the team to focus on innovation rather than firefighting.

“Four years without a major outage is a big deal,” Jürgen emphasized. “This kind of stability builds trust.”

Four Years of Decisions, Intact

Four years without a major outage is impressive on its own.  But more importantly, those four years are captured in an immutable event log. Every decision. Every rule change. Every input and output. Teams don’t need to rely on memory, old Slack threads, or tribal knowledge to understand what happened. They just look it up. That depth of history helps with everything from onboarding to audits to AI model training.

Real-World Impact: Empowering Partners and Customers

The benefits of the transformation extended far beyond technical success:

Faster Updates

Product changes now go live within minutes, enabling partners to respond to market shifts almost instantly.

Stronger Partner Relationships

The stability and reliability of the platform improved partner satisfaction and strengthened Otto’s reputation.

Competitive Edge

Near real-time updates allowed Otto to remain agile and even outpace competitors in a fast-moving market.

"In e-commerce, every second counts,” Jürgen explained. “With this system, we’ve built the foundation to keep winning.”

A Smarter Foundation for Smarter Tools

Otto built their decision system to be clear, traceable, and resilient from day one. That strong foundation now gives them a head start with AI. Whether it’s forecasting demand or detecting anomalies, new models can plug into the system without breaking transparency. Every decision — human or machine — is held to the same standard: explain what happened, and why. That consistency makes Otto’s automation smarter, not just faster.

The Role of Axoniq: A Collaborative Partner

Otto treated Axoniq as a partner rather than a vendor. 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.

Looking Ahead: Preparing for the Future

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.

Otto’s Blueprint for Success

Otto went from retailer to marketplace i without trading away stability. By rebuilding on event-driven principles, Otto scaled to 7,000+ partners and 60M products and kept a full record of every decision along the way.