Trans.eu: migrating to microservices without downtime using a temporary data aggregation service
About the project
Trans.eu is one of Europe's largest freight exchange platforms, connecting thousands of carriers, freight forwarders, and shippers every day. In 2017, the company began a strategic migration of its platform from a monolithic architecture to microservices. It employs several hundred people and serves customers across Europe.
Business
- Ensure uninterrupted access to company data throughout the migration, providing the new microservices platform with a consistent source of contractor information before all target services were available.
- Decouple the new platform from the legacy monolith, minimizing dependencies so both systems could evolve independently without blocking each other.
- Provide aggregated company statistics (including the number of submitted offers) to support business decisions made by marketplace users.
Technological
- Build a microservice from scratch that aggregated company data from heterogeneous sources: the legacy monolithic platform and gradually introduced microservices.
- Implement a unified read model containing company data, accessible across the new platform.
- Consume and process events from the messaging infrastructure in near real time.
Customer experience
The fireup.pro team delivered the project efficiently and professionally. Thanks to their commitment, we can continue expanding the use of data across our organization.
Piotr Sobala,
Product Owner, Trans.eu
From challenge
Key Challenges
Incremental migration - the new platform could not wait for full system completion
Incremental migration - the new platform could not wait for full system completion
Trans.eu was transitioning from a monolith to microservices, but the new services were delivered gradually. Meanwhile, newly developed platform components already required access to company data, including registered addresses, company details, and business activity statistics. At that stage, there was no single source of truth within the new architecture.
Data scattered across two technology worlds
Data scattered across two technology worlds
Some company information remained in the legacy monolith, while other data gradually became available through newly developed microservices. CBIF had to retrieve information from both environments simultaneously and merge it into a single, consistent representation, despite differences in data models and integration methods.
A facade between the legacy and modern platforms
A facade between the legacy and modern platforms
A critical requirement was that the new platform should never know where the underlying data originated. CBIF had to behave like a native microservice within the new architecture while internally retrieving part of its data from the legacy system. This required carefully designed APIs and a unified data model so that consumers remained completely unaware of the implementation details.
Planned obsolescence as a design requirement
Planned obsolescence as a design requirement
CBIF was intentionally designed as a temporary solution. Once the new platform matured and dedicated microservices took ownership of company data, CBIF would no longer be needed. The challenge was to build a production-grade solution without overengineering functionality that would eventually be replaced.
Key functional and non-functional requirement
Functional
- Aggregate company data from domain events published by microservices through the messaging infrastructure, as well as directly from legacy databases.
- Provide a unified read model exposing standardized company information through REST APIs.
- Aggregate business statistics, including historical records and the number of submitted freight offers.
- Process domain events within an event-driven architecture using microbatching.
Non-functional
- High availability to ensure uninterrupted access to company information for platform consumers.
- Full observability through production monitoring and operational metrics.
- Isolation from the legacy system so that changes or retirement of the monolith would not affect CBIF consumers.
Through the solution
Through the solution
A transitional facade architecture
fireup.pro built CBIF as an independent microservice based on Domain-Driven Design (DDD). The service consumed events from RabbitMQ—published both by newly developed microservices and by adapters reacting to changes in the legacy monolith—and used them to build and continuously update a read model stored in Elasticsearch.
Consumers on the new platform interacted exclusively with the CBIF REST API, remaining completely unaware of where the underlying data originated. As new microservices gradually took over additional business domains, CBIF seamlessly adapted its internal data sources without requiring any changes from consuming services.
Data processing approach
Domain events from the messaging queue were processed using a microbatching approach, enabling efficient aggregation of data from multiple sources. Elasticsearch provided fast access to the read model, while Redis reduced latency through caching.
Service configuration was managed with Consul, allowing dynamic adaptation to the evolving microservices environment.
Quality assurance and testing
CBIF's reliability was critical—incorrect company data could lead to poor business decisions by marketplace users. The team adopted a Behavior-Driven Development (BDD) approach with Serenity to automate API and end-to-end testing, while WireMock isolated external dependencies. Load testing validated the service under production-scale event volumes, and Grafana and Kibana provided continuous operational monitoring.
To the success
Technological outcomes
The new platform became independent of the legacy monolith
No service consuming company data had to integrate directly with the legacy system. CBIF served as the single integration point, significantly simplifying the platform architecture throughout the migration.
A consistent read model throughout the migration
Company data remained available in a unified format from day one, regardless of the migration progress of individual system components.
Seamless service retirement
Once the new platform matured and dedicated microservices took over company data management, CBIF was retired and replaced by a dedicated company profile service without disrupting any consumers.
Business benefits
Trans.eu was able to migrate incrementally without forcing simultaneous migration of all business domains, significantly reducing project risk.
Newly developed platform components gained immediate access to contractor information instead of waiting for the entire migration to be completed.
The temporary solution was designed so effectively that its retirement required no modifications on the consumer side.
Project team
Adam
Software Architect
Tech stack
Java8
Spring Boot
Maven
Spring Integration
RabbitMQ
Elasticsearch
Liquibase
Redis
Serenity
Your success is our success
See how we can build a technological advantage for your company together.
We have a team that truly knows its stuff — we'll help you find a solution that works.
Conclusions & recommendations
Temporary services are a valid migration strategy
System migrations are typically approached in one of two ways: either freeze the existing platform until the new solution is fully completed or develop the new platform independently and synchronize both environments only at the end. <br><br>CBIF demonstrated a third approach: introducing a temporary aggregation service that allows the new platform to evolve independently while gradually replacing legacy functionality. Once dedicated microservices assume ownership of the data, the temporary service can be safely retired.<br><br>
The Facade pattern protects consumers throughout the migration
Services consuming company information never needed to know where the data originated. This made it possible to replace internal data sources without requiring any modifications on the consumer side—a textbook implementation of the Facade pattern delivering tangible operational benefits during large-scale migrations.
Event-driven architecture simplifies data aggregation
Collecting information by consuming domain events instead of querying databases directly decoupled CBIF from the internal implementation of upstream systems. Integrating additional data sources required only publishing compatible domain events, without modifying the aggregation service itself.
Observability is essential for business-critical services
CBIF served as the single source of company information for the entire new platform. Grafana and Kibana enabled the engineering team to identify operational issues before they affected end users, making comprehensive observability an essential part of the solution rather than an optional enhancement.
