Building the Integration Engine that Cuts Quext Property Onboarding from Six Months to Two Days

Custom ESB architecture: why Zato and Mule ESB were discarded and what replaced them

The first decision was architectural: Quext needed a data integration layer capable of ingesting events from multiple PMS systems, IoT devices, a digital leasing agent, and resident-facing portals without a separate integration build every time a new partner joined. Ideas2IT evaluated

1. Zato, which failed on scalability, Kafka support, and service reliability under load. Mule ESB was assessed and rejected on configuration complexity and cost.
2. The team built a custom cloud-native ESB on AWS EKS with Amazon EventBridge Scheduler handling job execution, a Generator-Worker architecture managing data ingestion, and DBT handling transformation.
3. The design constraint was that adding a new PMS partner would require configuration, not code.

This Phase Produced

• Custom cloud-native ESB (Built on AWS EKS, replacing evaluated Zato and Mule options)
• Generator-Worker ingestion architecture (Adapts to diverse partner configurations without custom builds)
• Amazon EventBridge Scheduler integration (Accurate job execution and scheduling across partner sync)
• DBT transformation pipeline (Data normalization layer before downstream service delivery)
• REST API inference layer (Consumer-specific data delivery for Quext service endpoints)
• Partner onboarding configuration framework (New PMS integration via config, not engineering build)

Debezium CDC pipeline and partner integrations: 8 PMS systems, 4,850 IoT devices, real-time sync

The event-driven layer required a CDC mechanism capable of monitoring Quext service databases continuously and dispatching changes to a Kafka bus within the AWS MSK cluster the moment data was modified. Debezium was instrumented across the specified tables to produce this near-real-time event stream.

IoT device data from 4,850 connected units entered the same bus, consumed by the same downstream services as PMS events: unit availability, lease state, tour scheduling, and resident check-in status. The Quext IoT service, Resident Portal, Digital Human leasing agent, and Connect product all drew from the same real-time event stream.

AWS SNS and SQS routed events to the correct consumers. With this architecture, a lease created in an integrated PMS system triggered resident check-in access without human reconciliation.

This Phase Produced

• Debezium CDC instrumentation (Near-real-time database change capture across Quext services)
• AWS MSK (Kafka) event bus (Central broker for all PMS, IoT, and platform events)
• IoT device integration layer (4,850 devices connected through unified event pipeline)
• PMS partner integrations (8) (Resman, Yardi, and 6 additional PMS systems integrated)
• AWS SNS / SQS consumer routing (Event fan-out to Quext IoT, Portal, Digital Human, Connect)
• Audit and observability pipeline (Full orchestration audit trail; Kibana + Grafana monitoring)

QA framework and smart search engine: test coverage and data-driven property search at scale

With integrations live across 29 communities, the team built out two parallel workstreams. The QA framework required validating transformed data from the integration engine against source API responses, databases, and Quext product UIs for IoT, Digital Human, and resident portals.

Test cases were managed in Xray inside Jira; Selenium and Behave BDD provided automated regression coverage. A separate CDC-based search engine was built to solve property search across the Quext platform: Debezium captured data changes across Quext service databases and pushed them to an OpenSearch index, enabling fast, configurable search across residents, tasks, users, and vendors.

Grafana and OpenSearch provided the observability layer that let the team identify sync failures before they surfaced to property managers or residents.

This Phase Produced

• BDD QA framework (Selenium + Behave) (Automated integration regression across all Quext products)
• Xray / Jira test case management (Organized test execution tracking, Swagger documentation)
• CDC-based smart search engine (Near-real-time OpenSearch index powered by Debezium CDC)
• OpenSearch index pipeline (Search across residents, tasks, users, vendors, units)
• Grafana + Kibana observability stack (Sync health monitoring and alerting across all integrations)
• Security compliance layer (MFA, IAM roles by job function, Cognito identity management, API ACL entries)