The Moment That Changed It——When a returning VIP guest stepped into the lobby, her host was already there. A real-time alert had been triggered the moment she completed check-in. Her past preferences were already surfaced; curated offers were being prepared before she even asked.
What made this possible wasn’t just technology—it was a shift in how the organization thought about data: not as something to analyze tomorrow, but something to act on now.
It’s not just data anymore—it’s about being able to respond before the guest even asks.
Background & Challenge: From Fragmented Truths to One Real-Time View
A Hospitality & Gaming group operates one of Macau’s leading integrated resorts—offering a unified brand across hotels, F&B, high-end retail, entertainment venues, and expansive casino floors. But behind the scenes, it was anything but unified.
Over the years, growth brought fragmentation. F&B ran on Oracle. Loyalty systems relied on PostgreSQL. Gaming platforms lived in SQL Server. Many teams still passed Excel files between departments. Guest data was locked across more than 100 systems, and different teams saw different truths.
Marketing wanted new use cases. IT needed 99.9% uptime. Developers wanted modern tools. We had to bring everyone into the same rhythm—fast but safe.
The goal became clear: build a real-time Operational Data Hub (ODH) to unify fragmented data, deliver consistent experiences across all guest touchpoints, and avoid the costly cycle of rebuilding pipelines per use case.
The Turning Point: From Blueprint to Delivery
While the strategic vision was clear—customer-centricity, operational efficiency, and revenue growth—the path forward wasn’t. Long waterfall cycles often took 6 to 12 months, while business needs shifted by the week.
So the team restructured around three principles:
-
Agile delivery: two-week sprints, tight business feedback loops, and faster time-to-market;
-
Microservices architecture: decoupling monoliths to isolate changes and reduce cross-system risks;
-
AI in the dev loop: piloting AI-assisted code generation, testing, and deployment in selected teams.
This wasn’t just IT transformation—it was an organizational one. Teams from marketing, PR, hotel operations, retail, and security began working as one. Cross-functional coordination became the norm.
The TapData Solution: Real-Time, Multi-Source, API-Ready
After validating with a POC, the team chose MongoDB and TapData to power their new real-time foundation:
-
MongoDB served as the central operational store—housing both detail-level and incremental guest views, with flexible schemas and scalable performance;
-
Together, they supported governed, reusable APIs that enabled every downstream app—from mobile to membership to gaming ops—to serve the same version of the truth.
TapData gave us fast pipelines with built-in schema adaptation. MongoDB let us store, search, and serve guest data at scale. That combination became our operational core.
Architecture at a Glance
Below is a simplified architecture that powers the real-time Guest 360 platform:
-
Source Systems: Diverse systems including Gaming, PMS, POS, Retail, and Entertainment feed real-time data into the platform. These span Oracle, PostgreSQL, SQL Server, and file-based sources like Excel.
-
TapData CDC Layer: TapData captures changes using log-based CDC, performs schema normalization and field-level transformations, and streams events with sub-second latency.
-
MongoDB Operational Store: The data is landed as incremental and detail-level views inside MongoDB, enabling flexible schema evolution and strong read/query performance.
-
Change Streams & APIs: MongoDB Change Streams power downstream applications (real-time dashboards, mobile apps, marketing systems), while TapData exposes governed REST APIs per business domain (Customer, Loyalty, Offers, etc.).
-
Single Source of Truth (SSOT): Together, TapData and MongoDB form a resilient, API-first, real-time data layer for all guest-facing and analytics use cases.
We landed on this architecture because it balances flexibility with real-time demands. We don’t need to rebuild pipelines—we publish data once and serve it everywhere.
Step-by-Step: Building the Guest 360 ODH
Step 1 — Connect sources & target. Establish CDC pipelines from Oracle, SQL Server, PostgreSQL into a MongoDB replica set.
Step 2 — Stream high-value domains. 20–30 critical tables across loyalty, bookings, gaming play, spend, and service streamed into the hub.
Step 3 — Normalize to Foundation Data Model (FDM). Relational structures mapped into a consistent guest model to enable reuse across touchpoints.
Step 4 — Merge into wide operational views. TapData’s Master-Slave-Merge logic consolidated guest attributes into app-optimized documents.
Step 5 — Construct live Guest 360 profiles. Identifiers, interactions, and histories (play, bookings, loyalty) were harmonized into a continuously updating profile.
Step 6 — Publish as domain APIs. Versioned REST APIs (Customer, Membership, Offers, Balances) powered mobile apps, POS, analytics, and internal dashboards—all consuming from the same source.
Quick Win: Real-Time Concierge Alerts
The team’s first “quick win” validated both vision and velocity:
In just 12 weeks, with 8 engineers, the team launched a real-time notification engine that alerted hosts the moment a VIP guest arrived. Alerts weren’t just triggered by static flags—they were filtered through live business rules and historical behavior.
We used to assume this would take 8–12 months. Instead, we launched in a quarter—and it immediately made service feel personal again.
Now, instead of waiting for check-in reports, staff could act instantly, offering the right dining, retail, or entertainment touchpoint—while the guest was still present.
Impact: From Lagging Data to Live Experiences
-
95% reduction in guest data lag
-
Guest 360 profiles updated in real time
-
Analytics, apps, and front-line teams consume the same APIs
-
No more rebuilding pipelines per team or channel
-
Availability measured at 99.95%
The architecture doesn’t just enable speed—it ensures consistency. Whether a guest visits a boutique, sits down for dinner, or plays on the casino floor, every interaction draws from the same live data layer.
The experience finally feels consistent. We add new use cases by plugging into the hub—not by wiring another fragile feed.
Conclusion
Within weeks, teams shifted from reconciling spreadsheets to building experiences on a single operational truth. Front-of-house staff saw consistent balances, tier, and preferences; digital channels rendered offers and availability off the same profile; analytics tapped fresh operational data without waiting on nightly jobs. Marketing moved to always-on personalization; ops improved service recovery with a complete interaction history; and compliance gained clear lineage from source to service.
Most importantly, the organization stopped “re-building the same pipelines” per use case—new products now plug into the ODH’s APIs and incremental views, accelerating time-to-market while keeping the experience consistent everywhere. (Near-real-time sync, API publishing, and the ODH architecture are core TapData capabilities used here.)
This success wasn’t driven by technology alone. It came from clear business alignment, cross-functional execution, and a commitment to operational agility. MongoDB and TapData provided the foundation—but the change was organizational.
It’s not about new systems. It’s about making sure the guest never feels like they’re moving between them.
