RWE Energy Platform
Migration and performance work on an energy-market data platform for one of Germany's largest energy companies.
The problem
RWE's energy-services platform depended on legacy Java components that were difficult for the team to extend. Energy-market data had to be queried, filtered, and exported daily. Large dataset exports took 45 minutes, and response times were slow enough to affect day-to-day analyst workflows.
The business needed faster data access and a codebase a small team could evolve safely. My work focused on the Node.js / NestJS replacement path, the data-filtering pipeline, and the tests needed to keep migration work controlled.
How I approached it
We moved replacement work into Node.js with NestJS and MongoDB. Energy projects have dynamic properties, so the filtering system needed to generate columns from each project's characteristics. I built and tuned this path with MongoDB aggregations, using profiling to find the expensive parts before changing them.
The biggest technical constraint was heavy processing on the main thread. I implemented worker pools to move large dataset operations into parallel work, which brought export time from 45 minutes down to 12. The profiler helped separate real bottlenecks from guesses.
I also introduced TDD early for the features I owned. On a migration the risk is replacing working behaviour with something subtly different, and the tests are what catch that.
Key technical decisions
Worker pools for exports
Large dataset operations were blocking the event loop. Worker pools moved heavy processing to parallel threads, keeping API work responsive while exports ran separately. 45 min became 12. The technique is isolated and measured in a demo you can run in your browser.
Profiler-driven optimization
I used the Node.js profiler to find where time was actually spent in the column-filtering pipeline, then optimized the MongoDB aggregations that were genuinely responsible for the slowdown.
Dynamic column generation
Energy projects have variable properties. The filtering system generates columns dynamically from project characteristics — flexible enough for any project shape, fast enough for daily use.
TDD from day one
On a migration, replacing working behaviour is the risk. I used test-driven development for the features I owned, so changes could be reviewed against expected behaviour, not intent alone.
Business impact
- 65%
- Faster API responses
- 45 → 12 min
- Export time (≈73% faster)
- 15,000+
- Daily queries handled
The 65% API improvement made market-data workflows faster for users who queried the system daily. The export-time reduction turned exports from an overnight-style task into something analysts could run during the workday. The NestJS structure also gave the 4-person team a clearer path for follow-up work.
What I took away
On a small team replacing a production system, every week had to move the migration forward by a predictable amount, which meant scoping work tightly and saying where it had got to.
The performance work is where I learned to profile first. The bottleneck was not where I assumed it was, and checking before changing anything saved a lot of time.