The workflow before#
Quext builds smart home and property technology for multifamily communities: smart locks, thermostats, leak sensors and access points that generate millions of events a day. Property managers rely on that data to spot problems before residents do. But batch pipelines refreshed dashboards only every 15 to 30 minutes, and an urgent alert like a leak took 10 to 15 minutes to arrive. Pipelines ran at about 92% uptime, and engineers spent mornings fixing failed jobs. At the same time Quext was rewriting its monolithic property management application into microservices, and each new service needed reporting on day one without slowing developers down.
What we built#
We built Quext a streaming data layer for its devices and one shared set of metric definitions on top. Device events flow to dashboards and alerts as they happen, every role sees the same numbers, and the pipelines check their own health. For the microservices rewrite, we gave developers a tested pattern for reporting so each new service arrives ready to measure.
Events that arrive as they happen
Device events now stream in instead of waiting for a batch, so a property manager's dashboard updates in under 5 seconds and a leak alert lands in under 30. We split the stream by device type, event class and alert severity, so a burst of thermostat readings never delays a leak warning.
One definition for every metric
A semantic layer defines each metric once, such as device uptime, maintenance response time, energy efficiency and cost per unit, and serves it to role-based dashboards for property managers, portfolio owners and maintenance staff. Row-level security means each customer sees only its own communities. We put definitions in one layer because three dashboards with three versions of uptime is worse than one slow dashboard.
Pipelines that report on themselves
Orchestrated models run with schema, freshness and completeness checks, and the team sees pipeline health, quality scorecards and failure alerts in one view. Problems show up as alerts, not as a property manager's complaint. Uptime went from about 92% to 99.5%.
A reporting pattern for each new service
We used a smaller application, Digital Human, as a low-risk pilot: we built its dimensional model and data marts and tried embedded dashboard options. The result became a checklist and target schemas developers build each new service toward, so shipping a new metric takes 2 to 3 days instead of 2 to 3 weeks.
How we delivered it
We moved the device stream and semantic layer first, since property managers felt the lag most, then hardened the pipelines, then ran the Digital Human pilot alongside Quext's engineering team so the pattern came from real work rather than a slide.
Before and after#
| Measure | Before | After |
|---|---|---|
| Dashboard refresh | 15 to 30 minutes | Under 5 seconds |
| Urgent alert delivery | 10 to 15 minutes | Under 30 seconds |
| Data pipeline uptime | About 92% | 99.5% |
| Shipping a new metric | 2 to 3 weeks | 2 to 3 days |
What's next#
With one governed metric layer over device, energy and operations data, Quext can let property managers ask questions of their portfolio in plain English and get answers built on the same definitions. The same device history is the training data for predictive maintenance, flagging equipment before it fails.
