ZENAVA
Guides
Start typing to search…

Architecture of CTICloud

1. The Critical Importance of Architecture

Contact center platforms serve as the core infrastructure supporting enterprise operations and customer service excellence. Our architectural design meets the rigorous standards that enterprises demand from their contact center systems. The architectural philosophy and principles represent the soul of a platform product and demonstrate the comprehensive capabilities of a cloud platform service provider.

2. Architecture Design Goals, Philosophy, and Principles

When designing our cloud platform architecture, we focused our core efforts on effectively balancing stable service delivery with the evolutionary capabilities brought by scenario-driven innovation. Our challenge was to ensure large-scale, uninterrupted stable operation while enabling rapid functional evolution based on customer requirements and technological advancement.

Three core architectural design philosophies support this ambitious goal:

2.1 Layered Architecture Design with Inter-Layer Isolation

We decompose a complex, real-time system that demands both exceptional stability and flexibility into distinct layers, with each layer supporting specific business requirements. This transforms a complex monolith into a clearly structured 4-subsystem architecture. Simplified architecture enhances understanding and manageability, forming the foundation for sustained, efficient development.

2.2 Functional Decoupling Within Each Layer

With comprehensive mastery of contact center scenarios across all customer touchpoints, we can fully decompose functional modules. Modules interact solely through well-defined interfaces, enabling end-to-end high availability throughout the entire workflow.

2.3 Dual-Cloud Active-Active Design for Extreme Resilience

Customer contact systems represent the lifeline of enterprise operations. Extended service interruptions cause significant business impact. Therefore, we specifically design for extreme scenarios including natural disasters and regional infrastructure failures.

3. How We Achieve Our Architecture Design Goals

3.1 Architecture Layering

Our layered architecture design divides the overall system structure into four distinct layers:

Layer 1: Network Layer

  • IP network equipment and infrastructure
  • Carrier circuit networks and connectivity
  • Unified network management and control systems

Layer 2: Infrastructure Layer (IaaS)

  • Data center facilities and resources
  • Cloud computing platforms and services
  • Cloud storage solutions and backup systems
  • Internet access and connectivity infrastructure

Layer 3: API Layer (PaaS)

Drawing from years of accumulated expertise, we abstract business scenarios into extensive APIs and SDKs. These provide customer development teams with the tools to implement business logic according to their specific scenarios, enabling rapid integration of platform capabilities into internal business systems.

Layer 4: SaaS Layer

Delivers turnkey application functionality and comprehensive solutions that customers can deploy immediately without custom development.

These four layers operate independently, connected through predefined interfaces. Each layer can evolve, scale, and operate independently without affecting others. Inter-layer decoupling enables our network teams, infrastructure R&D, and application development teams to focus on specific layers, maximizing technical development efficiency.

Layered Architecture Diagram

%%{init: {'theme':'base', 'themeVariables': { 'primaryColor': '#ffffff', 'fontFamily': 'arial', 'fontSize': '12px'}}}%%
graph TB
    subgraph L4 ["📱 Application Layer (SaaS)"]
        A[Contact Center Applications]~~~
        B[CRM Solutions]~~~
        C[Analytics & Reporting]~~~
        D[Agent Workspace]
    end
    
    subgraph L3 ["🔌 API Layer (PaaS)"]
        E[OpenAPIs]~~~
        F[AsyncAPIs]~~~
        G[Webhooks]~~~
        H[Server SDK]~~~
        I[Agent SDK]~~~
        J[RTC SDK]
    end

    subgraph L2 ["☁️ Infrastructure Layer (IaaS)"]
        K[Cloud Provider A]~~~
        L[Cloud Provider B]~~~
        M[IDC A]~~~
        N[IDC B]
    end
    
    subgraph L1 ["🌐 Network Layer"]
        P[IP Network]~~~
        Q[PSTN Network]~~~
        R[Network Control Systems]
    end
    
    %% Layer-to-Layer Relationships
    L4 -.->|"API Calls"| L3
    L3 -.->|"Service Requests"| L2
    L2 -.->|"Network Traffic"| L1

3.2 Decoupling Within Layers

3.2.1 Network Layer Decoupling

SD-WAN Implementation: We implement SD-WAN networking solutions to separate network hardware and circuits from the control platform, achieving full connectivity between all nodes within the core network. SD-WAN provides real-time network status detection capabilities, enabling millisecond-level automatic switching when any node fails. This approach delivers both large-scale stable operation and centralized, flexible traffic management.

Multi-Data Center Design: We implement core data center separation through strategic geographic distribution. We operate two core data centers each in Beijing and Shanghai, with all four facilities interconnected via SD-WAN. When any data center experiences issues, we can seamlessly transfer operations to other core facilities, ensuring cross-regional high availability.

3.2.2 IaaS Layer Decoupling

Our cloud platform operates simultaneously on two leading cloud service providers. Each core data center connects via dedicated fiber optic links to both cloud platforms, linking two different cloud service providers. When either cloud service provider experiences issues, we can transfer operations to the alternative cloud infrastructure.

Through network layer and IaaS layer decoupling, we achieve infrastructure load balancing and high availability. When any data center or cloud service provider becomes unavailable, business operations can rapidly switch to alternative infrastructure. Business continuity never depends on any single data center or cloud service provider.

Infrastructure Abstraction Layer: At the software level, we abstract components from different cloud services into universal functions. This includes abstractions for cloud computing virtual hosts, cloud object storage, cloud databases, cloud load balancers, cloud cache services, cloud table services, cloud elastic scaling, and cloud serverless architectures. This makes cloud infrastructure environments transparent to developers, eliminating the need to understand cloud environment details or whether services run on AWS, Alibaba Cloud, or other providers. This enhances development efficiency while completely decoupling software from the IaaS infrastructure layer.

For both SaaS service models and VPC service models, software and IaaS decoupling ensures identical technical implementation using a unified software version. This eliminates project-specific software adaptations and provides the architectural foundation for future VPC model development.

Dual-Location, Dual-Cloud, Four-Core Data Center Infrastructure Topology

%%{init: {'theme':'base', 'themeVariables': { 'primaryColor': '#ffffff', 'fontFamily': 'arial', 'fontSize': '12px'}}}%%
graph TB
    subgraph NETWORK ["🌐 SD-WAN Control Center"]
        SDWAN[Centralized Management<br/>& Traffic Control]
    end

    subgraph SH ["🏙️ Shanghai Region"]
        
        subgraph IDCB ["IDC"]
            SH1[Shanghai IDC A]~~~
            SH2[Shanghai IDC B]
        end
        Cloud2[Cloud Provider B]
    end
    
    subgraph BJ ["🏛️ Beijing Region"]
        subgraph IDCA ["IDC"]
            BJ1[Beijing IDC A]~~~
            BJ2[Beijing IDC B]
        end
        Cloud1[Cloud Provider A]
    end

    %% Inter-region connectivity
    BJ1 <-.->|Fiber Link| SH1
    BJ2 <-.->|Fiber Link| SH2



    %% Control connections (simplified)
    NETWORK -.->|Management| SH
    NETWORK -.->|Management| BJ
    
    %% Internal connections within regions
    SH1 <-.->|Fiber Link| SH2
    BJ1 <-.->|Fiber Link| BJ2

    IDCB <-.->|Fiber Link| Cloud2
    IDCA <-.->|Fiber Link| Cloud1

3.3 API Layer: Platform Capability APIs Enable Customer Self-Service Development

Our PaaS layer provides over 500 API interfaces and multi-language development SDKs for customer development teams. These API interfaces include:

  • Channel Integration APIs: Multi-channel customer touchpoint management
  • Queue & Routing APIs: Intelligent call distribution and workflow management
  • Knowledge Base APIs: Centralized information and content management
  • Artificial Intelligence APIs: AI-powered automation and insights
  • CRM APIs: Customer relationship management integration
  • Ticketing APIs: Case and incident management systems
  • Reporting APIs: Analytics and business intelligence
  • Agent SDKs: Desktop and mobile agent applications
  • Softphone SDKs: VoIP communication capabilities
  • Configuration APIs: System and tenant management
  • Call Control/Session Management APIs: Real-time communication control
  • Session Recording APIs: Compliance and quality management
  • Real-time Statistics APIs: Live operational metrics
  • System Monitoring APIs: Infrastructure health and performance
  • Logging APIs: Audit trails and troubleshooting support

Enterprise customers' development teams primarily use these APIs and SDKs to integrate contact center capabilities into their internal business systems. Customer developers can implement customizations for different business scenarios based on these APIs, achieving the optimal balance between stable operation and customer customization requirements.

Typical Enterprise Customer API Integration Architecture

graph LR
    subgraph "Customer Internal Systems"
        C[CRM System]
        A[Agent Workspace]
        W[Workforce Management]
        B[Business Intelligence]
        O[Operate and Maintain System]
    end
    
    subgraph "CTICloud API Layer"
        API[CTICloud 500+ OpenAPIs]
        SDK[Agent/Server SDKs]
    end
    
    subgraph CTI ["CTICloud Platform"]
        direction LR
        CC[Contact Center Core]
        AI[AI Services]
        RPT[Reporting Engine]
        MON[Monitoring System]
    end
    
    C --> SDK
    A --> SDK
    W --> API
    B --> API
    O --> API
    
    API --> CTI
    SDK --> CTI

3.4 SaaS Layer Microservices and Rapid Evolution

Within the SaaS layer, we further decompose functional modules and implement comprehensive microservices architecture. Each module interacts solely through interfaces, operating, evolving, and scaling independently without interference. Every microservices module can implement independently scalable clusters.

We transform core communication components, communication protocol control, basic data storage and processing, media transcoding and recording, universal messaging channels and processing, call control and routing, and data interaction and push capabilities into APIs. Applications access and utilize these capabilities through API calls.

This approach resolves the contradiction between the high stability requirements of underlying communications and the rapid evolution needs of applications. The underlying communication layer ensures stability and performance without customization, while applications connect to the foundation through loose coupling. Based on over 10 years of customer service experience, we achieve the optimal balance between application flexibility and core system stability.

API Layer and SaaS Layer Decoupling Architecture

graph TB
    subgraph "SaaS Application Layer"
        APP1[Contact Center App]
        APP2[Analytics Dashboard] 
        APP3[Agent Desktop]
        APP4[Admin Console]
    end
    
    subgraph "API Abstraction Layer"
        API1[Communication APIs]
        API2[Data Processing APIs]
        API3[AI Service APIs]
        API4[Integration APIs]
    end
    
    subgraph "Core Platform Services"
        COMM[Communication Core]
        DATA[Data Processing]
        AI[AI Engine]
        INT[Integration Hub]
    end
    
    APP1 --> API1
    APP2 --> API2
    APP3 --> API3
    APP4 --> API4
    
    API1 --> COMM
    API2 --> DATA
    API3 --> AI
    API4 --> INT

With sufficiently rich, low-level, and open API interfaces, the SaaS application layer can rapidly implement diverse application forms through API calls. The SaaS application layer can evolve independently with application scenarios unrelated to the underlying PaaS.

4. Dual-Cloud Active-Active Contact Platform Architecture

Cloud platforms are uninterrupted operating systems where continuous stable operation forms the core foundation. For stability, we are the only domestic service provider capable of implementing dual-cloud active-active architecture. This capability is critical for enterprise customers because contact systems represent the operational lifeline of every enterprise. Service interruptions cause significant losses, requiring design for extreme scenarios including regional power outages, regional network interruptions, entire cloud service provider unavailability, and regional natural disasters.

We designed and built a dual-cloud active-active system. This means we simultaneously deploy systems on two heterogeneous cloud infrastructures from different suppliers. In China, we deploy the northern region on AWS and the southern region on Alibaba Cloud. Both platforms operate simultaneously, carrying business loads concurrently. Configuration data between cloud platforms achieves real-time (second-level) bidirectional synchronization through IDC-based real-time synchronization modules. Customers can simultaneously use Platform A and Platform B, enabling rapid switching between clouds during extreme scenarios.

4.1 Dual-Cloud Active-Active Architecture

graph TB
    subgraph "Northern Region - AWS"
        AWS1[Beijing AWS DC-1]
        AWS2[Beijing AWS DC-2]
        AWSAPP[AWS Application Stack]
    end
    
    subgraph "Southern Region - Alibaba Cloud"
        ALI1[Shanghai Alibaba DC-1] 
        ALI2[Shanghai Alibaba DC-2]
        ALIAPP[Alibaba Application Stack]
    end
    
    subgraph "Data Synchronization"
        SYNC[Real-time Sync<br/>Second-level Latency]
    end
    
    subgraph "Customer Access"
        CUST[Customer Applications]
        LB[Global Load Balancer]
    end
    
    AWS1 -.-> AWS2
    ALI1 -.-> ALI2
    
    AWSAPP --> SYNC
    ALIAPP --> SYNC
    
    CUST --> LB
    LB --> AWSAPP
    LB --> ALIAPP
    
    AWS1 --> AWSAPP
    AWS2 --> AWSAPP
    ALI1 --> ALIAPP
    ALI2 --> ALIAPP

5. Real-time Comprehensive Operational Metrics for Continuous Rapid Evolution

Health monitoring supports sustainable rapid evolution. Real-time, multi-dimensional business system operational metrics monitoring enables immediate detection of subtle system changes, establishing the foundation for continuous evolution.

Sustainable evolution architecture incorporates three core technical elements:

5.1 Dual-Dimension Gradual Deployment Design

We implement gradual deployment technology based on both customer segments and traffic percentages. New module versions initially deploy to select customers in limited quantities, monitoring operational metrics and customer feedback. When issues arise, we can rapidly rollback and resolve problems. After achieving stable operation, we gradually expand to higher percentages and additional customers.

5.2 Real-time Comprehensive Monitoring Design

We designed and developed a complete monitoring and operational support platform. We prioritize system operational metrics measurement through detailed and comprehensive monitoring, real-time statistics, and real-time alert systems. This monitoring foundation enables both stable platform operation and rapid evolution capabilities. Monitoring analyzes the operational status of each module, providing proactive alerts when metrics exceed warning thresholds.

5.3 Organizational Structure Support

We adopt DevOps integrated development and operations organizational structures, enabling tight collaboration between R&D and operations teams. We maintain smaller, more frequent changes to control evolution risks. Through automated testing technologies, we achieve weekly iterations on our public cloud PaaS platform, completing approximately 45 iterations annually while maintaining stable platform operation and seamless customer experiences.

We adhere to the principle "No Measurement, No Improvement". Any new functionality requires upfront design and definition of measurement metrics, with mandatory completion of metric development and monitoring threshold definitions before deployment.

6. Architecture Benefits and Business Value

6.1 Enterprise-Grade Reliability

  • 99.99% uptime through dual-cloud active-active architecture
  • Millisecond failover capabilities via SD-WAN technology
  • Zero single point of failure across all system components

6.2 Scalable Innovation Platform

  • 500+ APIs enabling unlimited customization possibilities
  • Microservices architecture supporting independent scaling
  • Weekly deployment cycles with zero-downtime updates

6.3 Global Infrastructure Resilience

  • Multi-region deployment across China's key economic zones
  • Dual cloud provider strategy eliminating vendor lock-in
  • Real-time data synchronization ensuring business continuity

6.4 Developer-Centric Design

  • Multi-language SDKs for rapid integration
  • RESTful API standards following industry best practices
  • Comprehensive documentation and development support

This architectural foundation positions CTICloud as the premier choice for enterprise customers requiring both stability and innovation agility in their contact center operations.

Updated 17 days ago