The problem
Trip planning features needed data that lived in multiple backend systems, each with its own shape.
Constraints
The source systems were owned by different teams.
Adding this responsibility to an existing shared platform service would have coupled unrelated work.
The decision
A separate NestJS microservice that aggregates and transforms data from the sources and exposes one REST API to the trip planning frontend.
The trade-off
One more service to deploy and monitor, in exchange for clear ownership and no new coupling in the shared platform.
Outcome
Trip planning features got the data they needed through a single, consistent API.