High Level Architecture Overview — ICPA, HTTP Streaming & SyncApp Manager
Why This Matters
This lesson reveals the supporting infrastructure that makes SyncApp reliable at scale — the ICPA proxy for rate limiting, HTTP streaming for efficient data transmission, the SyncApp Reporting Service for health monitoring, and the SyncApp Manager for write-back routing.
What You'll Learn
- ICPA (Integration Cloud Partner Adapter): the proxy that monitors and throttles all PMS API calls per location
- How ICPA feeds Prometheus metrics and a Grafana dashboard for monitoring 200/500/409 error rates
- HTTP streaming: sending headers once, then streaming multiple payloads over a single connection (vs REST's per-request overhead)
- SyncApp Reporting Service: tracks SyncApp health (up/down) and last sync time, stored in its own database
- SyncApp Settings service: stores per-location configurations (usernames, passwords, PMS-specific credentials)
- V2 write-back (MSQ queue) vs V3 write-back (SyncApp External API → SyncApp Manager)
- SyncApp Manager: manages WebSocket connections from thousands of SyncApps, routes write-back requests to the correct instance
Watch Video
Lesson Summary
The full architecture has several key supporting services. ICPA is a proxy layer between SyncApp and PMS APIs that enforces rate limits and feeds monitoring data to Prometheus/Grafana. HTTP streaming sends headers once and reuses the connection for multiple payloads — much more efficient than standard REST. The SyncApp Reporting Service monitors health and sync times. For write-backs, V2 used an MSQ message queue; V3 replaced this with a direct library-based approach through the SyncApp Manager. The SyncApp Manager maintains WebSocket connections to all active SyncApps and routes write-back requests to the correct instance using location/office IDs.