Compliance Detection Subsystem Rework

Overview

Our detection subsystem was originally built around a dependency graph that propagated resource changes into monitor updates. It worked through the development cycle but started putting too much pressure on the write path under production load, creating ingestion latency and reliability risk.

I owned the investigation, tracing the async path to understand where one resource change was turning into many writes. Detection updates were fanning out into per-entity work, so making an individual operation faster would still leave us doing too many of them.

What we did

I worked with a platform staff engineer on the redesign, while I drove the domain-event shape, payload enrichment, and read-path reconfiguration.

We turned dependency updates into domain events about monitor-resource changes, with batching and bulk ingestion to reduce per-resource overhead. That let consumers scale separately from dependency-graph updates. We also enriched event payloads so downstream evaluation could reuse the data instead of fetching or computing it again.

As part of the rework, I reconfigured the read path onto a maintained monitor-resource model over 5M+ rows. The event pipeline updated that model incrementally, so a query no longer had to reconstruct a monitor's resources from scratch. Indexes and changes to when filters were computed supported the read path, while the maintained model gave us a defined place to inspect and tune the data being evaluated.

A platform partner helped scope the immediate write-path fix while we worked toward the broader redesign. We needed relief on the existing path as well as a way to stop repeating the same work as the data grew.

Collaboration

The architecture work was a partnership with a platform staff engineer, and the platform team owned the event-infrastructure pieces the redesign depended on.

Outcome

• Batched events and bulk ingestion reduced the per-entity work in the dependency-update path.
• The read path stopped reconstructing monitor resources from scratch on every request.
• A maintained monitor-resource view made the read path over 5M+ rows easier to inspect and tune.

Tracing the full path changed the question I was asking. Once we could see how much work a single update triggered, the redesign could address that multiplication rather than treating each slow operation in isolation.