Virtual Power Plant at Eneco

Eneco — one of the largest energy providers in the Netherlands — runs a Virtual Power Plant (VPP) that aggregates thousands of distributed energy assets and optimizes them in real time against the energy markets. It is a demanding event-driven, cloud-native system: many microservices reacting to a constant stream of events, where correctness, resilience and horizontal scale are not features but requirements. This is exactly the class of system I specialize in — highly scalable, robust and highly reliable event-based cloud platforms.

I owned reliability for the entire programme, acting as the single cross-team owner of this concern. Rather than treating reliability as each team’s private problem, I made it a shared, first-class discipline across the organization.

Reliability patterns and anti-patterns. I consolidated the reliability patterns and anti-patterns discovered across the programme into a single, shared body of guidance, so every team could design for failure from the same playbook instead of relearning the same lessons independently.

A reusable eventual-consistency library. In an event-driven architecture the hardest problem is keeping independently-deployed microservices in agreement. I built a reusable eventual-consistency library that guarantees microservice states converge and match, and handed it to the teams as a drop-in foundation — turning a recurring source of subtle, high-severity bugs into a solved, shared capability.

Chaos testing across the fleet. I ran chaos testing across the VPP’s services, deliberately injecting failure to help each team prove that the services they own stay reliable under real-world faults. This turned “we think it’s resilient” into evidence, surfacing weaknesses before customers or the energy markets ever felt them.

Championing a faster, safer release workflow on the Fleet Optimizer. I led the Fleet Optimizer team and convinced programme management to adopt a trunk-based branching workflow, with our team chosen to lead the way as the first allowed to release this way — proving that shorter release cycles need not mean broken regressions. I built the pipeline in Azure DevOps so that branching off main and merging straight back deploys automatically through test, staging and production in sequence, with no manual release steps.

Spec-first, BDD end-to-end testing. I led the adoption of SpecFlow-based end-to-end tests for the Fleet Optimizer and, more importantly, changed when testing happened. Rather than treating scenarios as an afterthought, I convinced the team to define them with the product owner as part of each ticket, refine them before implementation, and write the test scenarios first, before any code. This surfaced the real scope of each ticket up front, kept us focused on delivering value, and — alongside full critical-path coverage structured to the testing pyramid — gave us the regression safety net that made fast, confident releases possible.

A partitioning strategy that unlocked Cosmos DB. When the team feared Azure Cosmos DB wouldn’t fit the Fleet Optimizer’s needs, I designed a partitioning strategy for the incoming forecast and asset data that showed a better way to model it. That opened the team to new data-management approaches and unlocked a move away from SQL Server to a cheaper, more flexible and horizontally scalable NoSQL foundation.

A reusable observability library. So teams didn’t reinvent logging for every microservice, I implemented a shared observability library for structured logging on top of Serilog — each service simply configures it instead of wiring logging from scratch. I added custom enrichers for specific cases using .NET behaviors, so contextual data is attached consistently across the fleet, making logs uniform, queryable and genuinely useful for tracing distributed, event-driven flows.

Removing operational bottlenecks with observability. Support for a heavily-used shared service had become dependent on one team member’s troubleshooting knowledge. I removed that bottleneck by building Azure dashboards that surfaced the reason for failures automatically — so any engineer could diagnose issues directly, with no need to pull in a specific person.

The through-line across all of this: I don’t just build reliable systems, I make reliability a repeatable, team-wide capability — through shared patterns, reusable libraries, automated verification, and observability that scales with the organization.