How we helped an enterprise climate-tech platform turn a slowing product into a more observable, efficient system

One of the first difficulties was visibility. There was no reliable end-to-end representation of what happened after a customer triggered a recalculation.

To investigate performance problems, we traced requests from the API downward, manually correlated log lines, followed the query path, and worked with engineers responsible for different parts of the processing pipeline to reconstruct what was happening.

That experience reinforced something we already suspected: improving performance would be difficult if every investigation began with detective work.

The backend had no consistent observability layer, making it difficult to identify bottlenecks and monitor services systematically. So observability became a foundational part of the solution rather than an operational afterthought.

As the platform moved toward a more distributed architecture, logs alone were not enough. Once a request crosses multiple services and processing stages, knowing that an error occurred is very different from knowing where time was spent, which service introduced the delay, which database operation was slow, or whether the bottleneck was application code or infrastructure.

We designed and implemented an observability framework based on OpenTelemetry. The choice was intentional: we wanted a vendor-neutral instrumentation layer rather than embedding AWS-specific monitoring code throughout every service.

We also deliberately favored controlled instrumentation over simply switching on broad automatic instrumentation. Automatic instrumentation would have been easier initially, but it provided less control over which signals mattered and how telemetry evolved over time.

To make adoption practical, we created a shared observability library so service owners did not need to understand all the details of OpenTelemetry. The framework standardized logs, metrics and traces and integrated them with the company’s existing AWS monitoring stack.

The practical outcome mattered more than the tooling. Before this work, engineers often had to hunt through logs and correlation IDs. Afterwards, they could trace a request through the system and see where time was actually being spent.

Observability did not merely help operate the system. It helped reveal what to optimize next.

During the engagement, another recalculation issue surfaced after a MongoDB version change. In one customer environment, a recalculation that should have completed much faster took approximately two days.

The team traced the problem to indexes that needed to be rebuilt. After correcting them, the same recalculation came down to roughly 14–15 minutes, with similar improvements observed in other environments.

This was not the centerpiece of the engagement, but it reinforced the same operating philosophy: performance problems should not immediately trigger architectural rewrites. They should trigger investigation.

The architecture review surfaced another performance problem. Some CPU-intensive worker processes were deployed alongside application services responsible for serving APIs.

Those two workloads have very different characteristics. An API process is largely optimized for I/O; a computational worker may consume CPU for extended periods.

Running both within the same deployment meant expensive worker activity could compete with customer-facing requests for resources.

We recommended separating the workers so they could be deployed and scaled independently. This also created the freedom to use a different language or runtime for computation in the future without forcing the rest of the platform to change with it.