Application Design & Tech Stack

CXOS — Customer Experience Operating System

Unified. Real-time. AI-Native. Built for the Future. This reference walks through the six-stage architecture that takes an event from a customer touchpoint all the way to real-time activation.

Every enterprise today runs on a patchwork of systems — a website, a mobile app, a CRM, a support desk, a call center, a dozen SaaS tools — each holding a different sliver of the same customer relationship. Marketing sees one version of the customer, support sees another, and no one sees the whole picture in time to act on it.

CXOS exists to close that gap: a single, real-time operating system that collects every interaction once, resolves it to one unified profile, and makes it usable everywhere it needs to show up — a personalized email, a support agent's screen, a machine learning model — without a dozen teams maintaining a dozen disconnected pipelines.

This site is both the architecture reference and the build plan for the engineering teams implementing it. Each of the six stages below is worked through as a concrete, implementable design: real .NET Core microservices on Azure, a shared NuGet-based ingestion contract every integration speaks, an open Iceberg lakehouse queryable by any engine, and dbt-modeled, AI-ready data underneath it all. All six stages are fully specified today, down to sample payloads and enterprise walkthroughs. Treat this as a living technical handbook — the plan is to keep it exactly as detailed as the code it's meant to guide.

🗃
One Data Foundation
Collect once, use everywhere
⚡
Real-time by Design
Stream, process, act instantly
🔗
Open & Composable
APIs, SDKs, Connectors
🧠
AI-Native
Intelligence across the stack
🛡
Privacy & Trust
Governance, consent, control
🌐
Built for Scale
Multi-tenant. Multi-cloud.

Architecture at a Glance

Full end-to-end diagram — click to zoom.

CXOS architecture diagram: Data Sources, Ingestion Layer, Transformation & Processing, Unified Data Foundation, Intelligence & Services, Destinations & Activation

Source diagram: doc/img/cxos-architecture.jpeg

The Six Verticals

Each vertical below drills down into its own reference page with submodules and a real-world example.

Full Application Service Map

Every deployable microservice across the six stages, and the database purpose-picked for its access pattern — one size does not fit all. Full DDD/CQRS breakdown lives in the BRD.

🌐
Azure Cosmos DB
Flexible-schema docs & graph traversal
🐘
Azure DB for PostgreSQL
Relational, ACID, joined data
⚡
Azure Cache for Redis
Hot-path caching, ephemeral state
📈
Azure Data Explorer
Time-series & telemetry (Kusto)
🪂
ADLS Gen2 (Iceberg)
The lakehouse itself
Stage 2 · SupportingCommand

📥 Ingestion

Cxos.Ingestion.Api
⚡Redis (cache only)
Stage 3 · SupportingCommand

⚙️ Event Processing

Cxos.Processing.Api
🪂ADLS Gen2 (Iceberg) 🌐Cosmos DB (checkpoints)
Stage 3 · SupportingQuery

📋 Schema Governance

Cxos.Processing.SchemaGovernance.Api
🐘PostgreSQL
Stage 4 · SupportingQuery

🏛️ Data Foundation & Governance

Cxos.Foundation.Api
🪂ADLS Gen2 (Iceberg) 🐘PostgreSQL (policy)
Stage 5 · Core DomainQuery

🥤 Customer Profile

Cxos.Profile.Api
🌐Cosmos DB (Core API) 🌐Cosmos DB (Gremlin) ⚡Redis
Stage 5 · SupportingBoth

🧠 Analytics & AI Insights

Cxos.Intelligence.Api
🐘PostgreSQL (semantic layer) 📈Data Explorer (scoring) ⚡Redis (query cache)
Stage 5 · SupportingBoth

🛠 Operational Services

Cxos.Operations.Api
🐘PostgreSQL (workflow, billing) 🌐Cosmos DB (alerts) 📈Data Explorer (quality)
Stage 6 · Core DomainCommand

📡 Activation

Cxos.Activation.Api
🌐Cosmos DB (dispatch log) ⚡Redis (frequency caps)
Generic Subdomain — Stateless Connectors (no dedicated database)
Cxos.Connectors.Salesforce Cxos.Connectors.Shopify Cxos.Connectors.Zendesk Cxos.Connectors.HubSpot Cxos.Connectors.ErpBilling Cxos.Connectors.Files Cxos.Connectors.Cdc Cxos.Connectors.Generic Cxos.Connectors.SendGrid Cxos.Connectors.Twilio Cxos.Connectors.AdPlatforms Cxos.Connectors.BatchExport

Microservices Architecture Diagram

Every Cxos.*.Api service from the map above, laid out as an actual flow — click to zoom.

CXOS microservices architecture diagram: inbound connectors flow into Ingestion, Event Processing (validated by Schema Governance), Data Foundation & Governance, then fan out to Customer Profile and Analytics & AI Insights (which signal Operational Services), converging on Activation and out through outbound connectors, with Observability, Security, Developer Platform, Multi-Tenancy, and Administration running horizontally beneath every service.

Source diagram: doc/img/cxos-microservices-architecture.svg — solid = real-time/command flow, dashed = batch/query flow, dotted = signals & cross-cutting. Full per-service detail (DDD layers, databases, integration points): click any card in the Service Map above, or see the BRD.

End-to-End Flow (Example)

How a single product-view event travels through this reference implementation's stack — Angular, .NET Core microservices on Azure, and PostgreSQL.

👤 User → 🌡️ Angular App — Product Viewed → 🔌 .NET Core API — Ingestion → 📶 Azure Event Hubs → ⚙️ .NET Core Worker — Stream Processing → 🐢 PostgreSQL — Unified Store → 📊 .NET Core API — Analytics → 💡 Insight (ML.NET) → 📤 .NET Core — Activation
Angular (SPA) .NET Core Web API (Docker on AKS) .NET Core Worker Service (IHostedService) Azure API Management Azure Event Hubs Azure Service Bus Azure Key Vault Application Insights Entity Framework Core PostgreSQL Cxos.Ingestion.Client (NuGet)
Reference Implementation

A customer views a product on the Angular storefront. Angular POSTs a ProductViewed event, via the shared Cxos.Ingestion.Client contract, to a .NET Core Web API ingestion endpoint — packaged as a Docker container on AKS, fronted by Azure API Management. The API publishes the event onto Azure Event Hubs; a .NET Core worker service (IHostedService) consumes it, deduplicates and enriches it, and persists it to PostgreSQL as the system of record. A .NET Core analytics API queries PostgreSQL (materialized views / window functions) to compute a propensity score, and the resulting insight triggers a .NET Core activation service — via Azure Service Bus — that sends a personalized email. Application Insights carries one distributed-tracing correlation ID through every hop, so if any step fails, the exception shows up already linked to the exact request that caused it.

Also Used Across the Platform

dbt (data build tool) Snowflake Azure Data Lake Storage Gen2 Azure Blob Storage Azure Purview Azure Cache for Redis Azure IoT Hub Azure Functions Azure OpenAI Service Azure Machine Learning Azure AD (Entra ID) + Azure AD B2C ADFS Azure Monitor

The Five Horizontals

Cross-cutting capabilities that run horizontally beneath every vertical above.

📈

Observability

Logs, Metrics, Traces

🔐

Security

IAM, Secrets, Threat Detection

🛠

Developer Platform

APIs, SDKs, Docs, Sandboxes

🏙

Multi-Tenancy

Isolation, Quotas, Limits

⚙

Administration

Users, Roles, Audit, Settings

Service Map

The horizontal counterpart to the Service Map above — same database legend, one card per cross-cutting capability.

Horizontal · Platform CapabilityBoth

📈 Observability

Cxos.Observability.Api
📈Data Explorer (logs, metrics, traces)
Horizontal · Platform CapabilityBoth

🔐 Security

Cxos.Security.Api
No CXOS-owned database — delegates to Azure Key Vault (secrets) + Azure AD / ADFS (identity)
Horizontal · Platform CapabilityQuery

🛠 Developer Platform

Cxos.DevPlatform.Api
🌐Cosmos DB (API catalog, sandbox state)
Horizontal · Platform CapabilityBoth

🏙️ Multi-Tenancy

Cxos.Tenancy.Api
🐘PostgreSQL (tenant registry, quotas)
Horizontal · Platform CapabilityBoth

⚙️ Administration

Cxos.Admin.Api
🐘PostgreSQL (users, roles, settings) 🪂ADLS Gen2 (audit logs, write-once)

Key Design Principles

  • Collect once, use everywhere
  • Real-time by default
  • Metadata drives everything
  • Open, extensible, and future-proof
  • Privacy, security, and governance baked-in
  • Built for scale and performance

Legend

  • Data Flow (Real-time)
  • Data Flow (Batch / Near Real-time)
  • Control / Metadata Flow