Technical Architecture

Platform Architecture &
Infrastructure Overview

For enterprise buyers, technical evaluators, and security teams. A complete view of Propeter's system design, AI pipeline, and infrastructure.

Architecture Philosophy

Propeter is built as a cloud-native, microservices-based platform with 15+ independently deployable services. The architecture is designed for three non-negotiable properties: reliability (the rate engine must never go down during a demand spike), accuracy (AI recommendations must reflect real-time market conditions), and isolation (no tenant's data or workload can affect another).

Principle 01
Microservices

15+ independent services. Each can be deployed, scaled, and updated without affecting others. Failure in one service is contained.

Principle 02
Event-Driven

Non-critical paths use async messaging (SQS). Critical paths (rate push, PMS sync) are synchronous with circuit breakers.

Principle 03
12-Factor App

Strict separation of config from code. Stateless application processes. No filesystem state. All config via environment variables and AWS Secrets Manager.

The 6-Agent AI Architecture

Propeter's core intelligence is delivered by a pipeline of six specialised AI agents. Each agent has a specific responsibility, data input, and output. The pipeline runs on a 4-hour cycle for standard updates, with Market Intelligence running independently every 15 minutes.

Agent 01
Data Ingestion Agent
PurposePull and normalise all source data
TechNode.js workers, SQS queue
InputsPMS reservations, rate plans, OTA availability
OutputsNormalised event stream to downstream agents
FrequencyEvery 4 hours + real-time webhooks
Agent 02
Market Intelligence Agent
PurposeMonitor competitor rates across OTAs
TechRedis pub/sub, distributed scraping
Inputs5–8 competitor property URLs per client
OutputsRate index, parity alerts, comp set delta
FrequencyEvery 15 minutes (independent cycle)
Agent 03
Demand Forecast Agent
PurposePredict future demand 365 days forward
TechPython ML service, XGBoost + LSTM ensemble
InputsHistorical bookings, events calendar, flight data, 200+ signals
OutputsOccupancy forecast per date, MAPE confidence score
FrequencyEvery 4 hours, full retrain weekly
Agent 04
Price Elasticity Agent
PurposeModel demand response to price changes
TechPython, statistical regression, Bayesian updating
InputsHistorical booking events, cancellation rates, segment data
OutputsPrice-demand curves per room type per segment
FrequencyEvery 4 hours, model updated with each new booking
Agent 05
RevPAR Optimisation Agent
PurposeFind revenue-maximising rate given all inputs
TechOptimisation engine, multi-variable solver
InputsDemand forecast, price elasticity curves, competitor rates, inventory
OutputsOptimal rate per room type per date (pre-guardrail)
FrequencyEvery 4 hours
Agent 06
Strategy Agent
PurposeApply business rules and produce final recommendation
TechRule engine, Node.js, PostgreSQL
InputsOptimal rate from Agent 05 + guardrails + business rules
OutputsFinal rate recommendation sent to Rate Engine for distribution
FrequencyEvery 4 hours + on-demand for manual triggers

Infrastructure Architecture Diagram

Seven layers from client to disaster recovery. Colour-coded by function.

Propeter Platform — Infrastructure Overview

Layer 1 — Clients
🌐 Web Browser (React 18)
📱 iOS Mobile App
📱 Android Mobile App
🔌 Partner API (REST)
↓ HTTPS / TLS 1.3
Layer 2 — Edge & Security
☁️ AWS CloudFront CDN
🛡️ AWS WAF (OWASP Rules)
🔀 Route 53 (DNS + Health Checks)
🛡️ AWS Shield (DDoS)
↓ Internal VPC
Layer 3 — Application Gateway
⚖️ Application Load Balancer
🔑 API Gateway (Auth + Rate Limit)
📦 ECS Fargate (Auto-scaling)
↓ Private Subnet (mTLS)
Layer 4 — Microservices (15+ services)
🧠 6 AI Agents
⚙️ Rate Engine (13 stages)
🔄 PMS Sync Worker
📡 Channel Manager
🎁 Loyalty Engine
🔔 Notification Service
↓ Private Subnet
Layer 5 — Data Layer
🗄️ PostgreSQL RDS (Primary)
📖 PostgreSQL (Read Replica)
⚡ Redis ElastiCache
📁 S3 Object Storage
🔍 OpenSearch
↓ Cross-Region Replication
Layer 6 — Disaster Recovery (secondary region)
🔁 RDS Read Replica (DR Region)
🔁 S3 Cross-Region Replication
🔁 Standby ECS Cluster

End-to-End Data Flow

How a rate recommendation is generated — from raw PMS data to a live rate on Booking.com.

1

PMS Data Pull (Every 4 hours)

Data Ingestion Agent connects to the hotel's PMS via REST API or webhook. Pulls new reservations, cancellations, modifications, and availability updates. Normalises data to Propeter's internal schema.

⏱ Duration: 30–90 seconds
2

Market Intelligence Refresh (Every 15 min)

Market Intelligence Agent independently scrapes competitor rates from configured OTA URLs. Updates the competitive rate index in Redis. Triggers parity alerts if violations detected.

⏱ Duration: 2–5 minutes across all monitored competitors
3

Demand Forecast Calculation

Demand Forecast Agent runs XGBoost + LSTM ensemble against 365-day forward window. Combines 200+ signals: historical pace, events calendar, flight search trends, weather, competitor availability. Outputs occupancy probability per date.

⏱ Duration: 45–120 seconds per property
4

Price Elasticity Calculation

Price Elasticity Agent models the booking probability curve at different price points for each room type on each date. Updated continuously with incoming booking events via Bayesian updating.

⏱ Duration: 10–30 seconds (incremental update)
5

Revenue Optimisation

RevPAR Optimisation Agent solves for the rate that maximises expected revenue: f(rate) = booking_probability(rate) × rate × remaining_nights × rooms. Produces a candidate rate per room type per date.

⏱ Duration: 5–15 seconds
6

Strategy Agent — Guardrails & Business Rules

Candidate rate is passed through the Strategy Agent which applies: floor/ceiling guardrails, min-stay restrictions, close-to-arrival rules, promotional overrides, and any manual rules the Revenue Manager has set. Produces the final recommendation.

⏱ Duration: <1 second
7

Rate Engine — 13-Stage Processing

Final recommendation enters the 13-stage Rate Engine: Base Rate → Inventory Adjustment → Rate Plan → Derived Rates → Promotion → Loyalty → Voucher → Referral → Flash Deal → Stacking Resolver → Guardrails → Upsell → Tax & Fee. Output: distribution-ready rate object.

⏱ Duration: <200ms p99
8

Channel Distribution

Rate object pushed to channel manager via REST API. Channel manager distributes to all connected OTAs (Booking.com, Expedia, MakeMyTrip, etc.). Rate confirmation received and logged. Parity check runs automatically.

⏱ Total round-trip to live OTA rate: <15 minutes

Integration Architecture

Propeter integrates with the hotel's existing technology stack — not replacing it, but intelligently orchestrating it.

🏨 PMS REST + Webhooks

OAuth 2.0 auth. Bidirectional sync. Supported: Opera Cloud, Mews, Cloudbeds, Clock, eZee, IDS Next, Hotelogix. Custom: REST API for others.

📡 Channel Manager HTNG / REST

SiteMinder, RateGain, Staah, Cloudbeds CM. Rate push + availability sync. <60 second push latency.

💳 Payments Tokenisation API

Windcave/Qvalent PCI DSS Level 1. Card numbers never touch Propeter systems. Token reference only.

📊 Accounting Xero REST API

OAuth 2.0. Real-time revenue sync. Auto-categorisation by room type, channel, rate plan. Nightly reconciliation.

📧 Email / SMS REST API

SendGrid (transactional email), Twilio (SMS). Guest communication sequences. Pre-arrival, upsell, post-stay.

📱 Push Notifications FCM / APNs

Google Firebase Cloud Messaging (Android), Apple Push Notification Service (iOS). Staff alerts and guest app notifications.

📈 Marketing CRM REST + Webhooks

mkng360.com integration. 360° guest profiles, campaign attribution, email marketing automation.

🔐 Auth / SSO OAuth 2.0 / SAML

Native login + SSO for Enterprise (SAML 2.0). Google Workspace SSO for staff. MFA enforced.

📋 Competitor Intel Proprietary Scraping

Lighthouse data + proprietary OTA monitoring. 200+ demand signals. 15-minute competitive rate refresh.

API Documentation

Propeter's REST API is available to Professional and Enterprise clients. Base URL: api.propeter.com/v2. Authentication: OAuth 2.0 bearer tokens (24h expiry + refresh rotation). Rate limits: 1,000 req/hour (Professional), 10,000 req/hour (Enterprise). Full documentation available in your account portal.

Performance & Scalability

ComponentSLA / TargetCurrent PerformanceScaling Model
API Response Time<500ms p95<180ms p95ECS auto-scale on CPU 70%
Rate Engine Processing<200ms p99<85ms p99Horizontal pod scaling
Rate Push to Channel<60 seconds<12 seconds avgAsync queue processing
OTA Rate Live<15 minutes8–12 minutes avgChannel manager dependent
Dashboard Load (CDN)<1.5s FCP<0.8s FCP (CloudFront)CloudFront edge caching
AI Forecast Cycle<4 hours2.5–3 hours per propertyParallel per-property workers
Platform Uptime99.9% monthly99.94% (last 12 months)Multi-AZ, auto-failover
Max Concurrent Properties10,000+Designed for 50,000Tenant-partitioned workers

Multi-Tenancy & Data Isolation

Propeter is a multi-tenant platform where hundreds of hotel properties share the same application infrastructure. Strict isolation ensures that no tenant's data, workload, or failure can affect another.

Hotel A (tenant_001)
Rate Data (tenant_001)
Guest Data (tenant_001)
AI Models (tenant_001)
Hotel B (tenant_002)
Rate Data (tenant_002)
Guest Data (tenant_002)
AI Models (tenant_002)
Hotel C (tenant_003)
Rate Data (tenant_003)
Guest Data (tenant_003)
AI Models (tenant_003)
Shared Infra
Application Code
AWS Infrastructure
Security Controls

Isolation Mechanisms

Database Layer

Row-Level Security (RLS) in PostgreSQL — tenant_id column on every table. Every query automatically filtered by tenant context. Cross-tenant queries are impossible at the database layer regardless of application bugs.

Application Layer

Tenant context loaded from JWT at request time. All service-to-service calls include tenant context header. No shared in-memory state between tenant requests. Separate Redis key namespacing per tenant.

AI Model Isolation

Each property has its own AI model instance. Model training data never crosses tenant boundaries. A property's demand patterns, pricing history, and guest data are exclusively used for that property's recommendations.

Resource Quotas

Per-tenant rate limits on API endpoints. AI compute quotas prevent one large property from monopolising forecast resources. Queue depth limits per tenant prevent noisy-neighbour effects.