Case study

Quext cut IoT dashboard refresh from 30 minutes to under 5 seconds

Property managers saw device data 30 minutes late, leak alerts lagged 15 minutes, and pipelines needed daily fixes.

Quext · Operations

99%faster dashboard refresh for property managers

The workflow before

Quext's smart locks, thermostats, leak sensors and access points generate millions of events a day across multifamily communities. Batch pipelines refreshed dashboards every 15 to 30 minutes, critical alerts took 10 to 15 minutes to arrive, and pipelines ran at about 92% uptime with failures fixed by hand. 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 development.

What we built

We moved device events onto Kafka (fed through API Gateway and Kinesis) so dashboards and alerts update as events arrive. A Cube.dev semantic layer defines each metric once, such as device uptime, maintenance response time, energy efficiency and cost per unit, and serves it with caching and row-level security to role-based dashboards for property managers, portfolio owners and maintenance staff.

Behind it, Airflow orchestrates dbt models with schema, freshness and completeness checks, landing data in Amazon Redshift for analytics, PostgreSQL for operational data and Snowflake for data sharing. Pipeline health, quality scorecards and failure alerts are visible to the team.

For the microservices rewrite we used a smaller application, Digital Human, as a low-risk pilot: we built its dimensional model and data marts on Redshift and QuickSight, evaluated Apache Superset for embedded dashboards, and turned the result into a checklist and target schemas that developers build each new service toward.

Before and after

MeasureBeforeAfter
Dashboard refresh15 to 30 minutesUnder 5 seconds
Critical alert delivery10 to 15 minutesUnder 30 seconds
Data pipeline uptimeAbout 92%99.5%
Shipping a new metric2 to 3 weeks2 to 3 days

What's next

With one governed metric layer over device, energy and operations data, the next step is Level 2: letting property managers ask questions of their portfolio data in plain English, and using the same history for predictive maintenance.

ShareLinkedInEmail

Ingestion: IoT devices post through API Gateway into Kinesis and on to Kafka topics partitioned by device type, event class and alert severity, with Kafka Streams handling real-time aggregates. Property management systems and third-party sources arrive by batch API and webhooks.

Modeling and storage: Airflow DAGs run incremental dbt models with schema validation, referential integrity and freshness tests. Redshift holds time-series optimized analytics tables, PostgreSQL the application backend and configuration, Snowflake shared and advanced analytics datasets. Cube.dev exposes metrics over REST, GraphQL and SQL with pre-aggregation caching and row-level security for multi-tenant access in the v3 Quext Cube application.

Microservices reporting: each new service lands its data into data marts defined against a shared dimensional model, proven first on the Digital Human application with Redshift and QuickSight; Apache Superset was evaluated as the embedded visualization layer. Infrastructure is Terraform, with services on Docker and Kubernetes.

Next step

Let's build the case study we tell next.