Skip to main content

Architecture Overview

This section provides a high-level overview of Deepdesk's architecture, including system components, data flows, and integration patterns.

Purpose​

The Architecture Overview documentation is designed to help:

  • Technical Leaders: Understand the system architecture and design decisions
  • Developers: Get oriented with the overall system structure before diving into specific components
  • Operations Teams: Understand deployment architecture and infrastructure components
  • Integration Partners: Learn how Deepdesk integrates with external systems

System Architecture​

Deepdesk is built as a cloud-native, multi-tenant platform deployed on Google Cloud Platform (GCP). The architecture follows microservices principles with clear separation between:

  • Global Services: Shared infrastructure and management services
  • Account-Specific Services: Isolated per-customer deployments
  • Integration Layer: Components that connect to external CX platforms

Key Architectural Principles​

Multi-Tenancy​

Each customer account runs in its own isolated Kubernetes namespace, ensuring:

  • Data isolation and security
  • Independent scaling and resource allocation
  • Customized configuration per account

Microservices Architecture​

Services are organized by function:

  • Admin: Account configuration and management
  • Backend: Core API and business logic
  • Engine: AI/ML processing and suggestions
  • Integration Components: Platform-specific widgets and data ingestion

GitOps Deployment​

Infrastructure and configuration are managed as code:

  • Terraform: Infrastructure provisioning
  • FluxCD: Continuous deployment from Git repositories
  • Helm: Service packaging and deployment

High-Level System Diagram​

Component Overview​

Global Services​

Onboarding Service​

Manages account provisioning and deployment across all regions and clusters.

  • Location: Cloud Run (global)
  • Purpose: Account lifecycle management
  • Access: Internal Deepdesk staff only

Account-Specific Services​

Admin Service​

Account-specific configuration and management interface.

  • Configuration: Service settings, credentials, integrations
  • Deployment: One instance per account namespace
  • Access: Account administrators and Deepdesk staff

Backend Service​

Core API and business logic for the account.

  • Functions: Message handling, suggestion retrieval, user management
  • Integration: Connects to CX platforms and frontend widgets
  • Data: Stores conversations and account data
  • Webhooks: Process incoming events from CX platforms.

Engine Service​

AI/ML processing and suggestion generation.

  • Processing: Real-time suggestion generation
  • Models: Text suggestions, URL suggestions, GPT models
  • Training: Continuous learning from conversation data

LLM Gateway Service​

Centralized gateway for GenAI features.

  • Purpose: Proxy for all LLM API calls
  • Provider Integration: Connects to Azure OpenAI and other LLM providers
  • Functions: Request routing, resilience (retry, failover routing)
  • Usage: Used by Backend for LLM-powered features (CX Assistants, Voice agents)

Integration Layer​

Frontend Widgets​

UI components embedded in CX platforms.

  • Types: Native integrations, browser extensions, iframe widgets
  • Platforms: Genesys Cloud, Salesforce, LivePerson, RingCentral
  • Features: Agent Assist UI, autocomplete, suggestions display

Data Flow Patterns​

Real-Time Suggestions Flow​

  1. Agent types in CX platform
  2. Frontend widget captures input
  3. Backend processes request
  4. Engine generates suggestions
  5. Suggestions displayed in widget

Webhook-Based Ingestion Flow​

  1. Conversation event occurs in CX platform
  2. Platform sends webhook to Deepdesk
  3. Webhook handler processes and validates
  4. Data stored in Backend database
  5. Engine processes for future suggestions

Training Pipeline Flow​

  1. Conversations accumulated in BigQuery
  2. Training pipeline triggered (manual or scheduled)
  3. ML models trained on conversation data
  4. Models deployed to Engine service
  5. New suggestions available for agents

Summarizer Assistant Flow​

  1. Conversation ends
  2. Frontend widget triggers summary request
  3. Backend receives conversation data and summary request
  4. Backend sends summarization prompt to LLM Gateway
  5. LLM Gateway calls Azure OpenAI with summarization prompt
  6. OpenAI generates structured summary (key points, sentiment, resolution)
  7. Summary returned to Backend
  8. Summary displayed in widget

Deployment Architecture​

Regional Clusters​

Deepdesk deploys to regional Google Kubernetes Engine (GKE) clusters:

  • Europe: Primary deployment region
  • Other Regions: Available based on customer requirements

Account Isolation​

Each account runs in an isolated namespace:

  • Namespace: Dedicated Kubernetes namespace per account
  • Resources: CPU, memory, and storage limits
  • Network: Network policies for traffic isolation
  • Secrets: Account-specific credentials and keys

Infrastructure as Code​

All infrastructure is managed through:

  • Terraform: GKE clusters, Cloud Storage, Cloud Functions
  • Helm Charts: Kubernetes service deployments
  • FluxCD: GitOps-based continuous deployment
  • Git Repositories: Source of truth for configuration

Security Architecture​

Authentication & Authorization​

  • User Authentication: SSO via OAuth2
  • Service-to-Service: API keys and service accounts
  • Platform Integration: Platform-specific OAuth2

Data Security​

  • Encryption at Rest: All stored data encrypted
  • Encryption in Transit: TLS for all connections
  • Anonymization: Optional PII anonymization
  • Data Isolation: Per-account database isolation

Network Security​

  • Private Clusters: GKE clusters not publicly accessible
  • Firewall Rules: Restricted ingress/egress
  • Cloud Armor: DDoS protection and WAF

Scalability & Reliability​

Horizontal Scaling​

Services scale independently based on load:

  • Backend: Scales with API request volume
  • Engine: Scales with suggestion generation demand
  • Frontend: Distributed via CDN

High Availability​

  • Multi-Zone Deployment: Services distributed across availability zones
  • Health Checks: Kubernetes liveness and readiness probes
  • Auto-Recovery: Automatic pod restart on failure

Monitoring & Observability​

  • Metrics: Prometheus for service metrics
  • Logging: Centralized logging to Cloud Logging
  • Tracing: Distributed tracing for request flows
  • Alerting: Automated alerts for service health

Next Steps​

To dive deeper into specific aspects of the architecture:

For operational documentation: