Visual representation of Company Manager's infrastructure and business processes

Architecture Diagrams

This page provides comprehensive visual representations of Company Manager's system architecture, business processes, and infrastructure using Mermaid diagrams.

System Architecture Overview

The following diagram shows the high-level architecture of the Company Manager ecosystem, including all applications, services, and data layers.

graph TB
    subgraph "Frontend Applications"
        WebApp["Main Web App<br/>(Next.js)"]
        Website["Marketing Website"]
        Docs["Documentation Site"]
        Mobile["Mobile App<br/>(React Native)"]
        Desktop["Desktop App<br/>(Electron)"]
        ChromeExt["Chrome Extension"]
        VSCodeExt["VSCode Extension"]
    end

    subgraph "API Layer"
        TRPC["TRPC Router<br/>(Type-safe API)"]
        RestAPI["REST API<br/>(Go Service)"]
        GraphQL["GraphQL API<br/>(Optional)"]
    end

    subgraph "Go Microservices"
        APIGo["API Service<br/>(Go)"]
        QueueMgr["Queue Manager<br/>(Go)"]
        AsynqQueue["Asynq Job Queue<br/>(Go)"]
        InfraDash["Infrastructure Dashboard<br/>(Go)"]
    end

    subgraph "Data Layer"
        PostgreSQL[(PostgreSQL<br/>Database)]
        Redis[(Redis<br/>Cache & Sessions)]
        Prisma["Prisma ORM"]
    end

    subgraph "External Services"
        Stripe["Stripe<br/>(Payments)"]
        Email["Email Service<br/>(Resend)"]
        Storage["File Storage<br/>(S3/Local)"]
        Webhooks["Webhook Services"]
    end

    subgraph "Infrastructure"
        Docker["Docker<br/>Containers"]
        K8s["Kubernetes<br/>(Production)"]
        LoadBalancer["Load Balancer"]
        Monitoring["Monitoring<br/>(Prometheus)"]
    end

    %% Frontend to API connections
    WebApp --> TRPC
    Mobile --> RestAPI
    Desktop --> TRPC
    ChromeExt --> RestAPI
    VSCodeExt --> RestAPI

    %% API to Services
    TRPC --> APIGo
    RestAPI --> APIGo
    GraphQL --> APIGo

    %% Services to Data
    APIGo --> Prisma
    QueueMgr --> Redis
    AsynqQueue --> Redis
    InfraDash --> PostgreSQL

    %% Data connections
    Prisma --> PostgreSQL
    APIGo --> Redis

    %% External integrations
    APIGo --> Stripe
    APIGo --> Email
    APIGo --> Storage
    APIGo --> Webhooks

    %% Infrastructure
    APIGo --> Docker
    QueueMgr --> Docker
    AsynqQueue --> Docker
    Docker --> K8s
    K8s --> LoadBalancer
    K8s --> Monitoring

    style WebApp fill:#e1f5fe
    style APIGo fill:#f3e5f5
    style PostgreSQL fill:#e8f5e8
    style Redis fill:#fff3e0

Key Components

Frontend Applications: Multiple client applications serving different use cases
API Layer: Type-safe TRPC and REST APIs for different client needs
Microservices: Go-based services for performance-critical operations
Data Layer: PostgreSQL with Prisma ORM and Redis for caching
External Services: Third-party integrations for payments, email, and storage
Infrastructure: Containerized deployment with Kubernetes orchestration

Multi-Tenant Architecture

This diagram illustrates how tenant isolation works across the system, ensuring data security and proper access control.

graph TD
    subgraph "Multi-Tenant Architecture"
        User[User]
        
        subgraph "Tenant A"
            TenantA["Tenant A<br/>Organization"]
            SiteA1["Site A1<br/>Main Office"]
            SiteA2["Site A2<br/>Warehouse"]
            DataA[("Tenant A Data<br/>Isolated")]
        end
        
        subgraph "Tenant B"
            TenantB["Tenant B<br/>Organization"]
            SiteB1["Site B1<br/>HQ"]
            SiteB2["Site B2<br/>Branch"]
            DataB[("Tenant B Data<br/>Isolated")]
        end
        
        subgraph "Shared Infrastructure"
            Auth["Authentication<br/>Service"]
            API["API Layer<br/>(TRPC/REST)"]
            DB[(Shared Database<br/>with Tenant Isolation)]
            Cache[(Redis Cache<br/>with Tenant Keys)]
        end
    end

    %% User access flows
    User --> Auth
    Auth --> TenantA
    Auth --> TenantB

    %% Tenant to sites
    TenantA --> SiteA1
    TenantA --> SiteA2
    TenantB --> SiteB1
    TenantB --> SiteB2

    %% API access with tenant context
    SiteA1 --> API
    SiteA2 --> API
    SiteB1 --> API
    SiteB2 --> API

    %% Data isolation
    API --> DB
    API --> Cache
    DB --> DataA
    DB --> DataB

    %% Tenant filtering
    DataA -.->|"WHERE tenantId = 'A'"| DB
    DataB -.->|"WHERE tenantId = 'B'"| DB

    style User fill:#e3f2fd
    style TenantA fill:#e8f5e8
    style TenantB fill:#fff3e0
    style DB fill:#f3e5f5
    style Auth fill:#fce4ec

Tenant Isolation Features

Data Isolation: All database queries include tenant-specific filters
Site-Based Organization: Multiple sites per tenant for complex organizations
Shared Infrastructure: Cost-effective shared services with proper isolation
Authentication Context: Users are authenticated within their tenant scope
Cache Separation: Redis keys are prefixed with tenant identifiers

Business Process Flow

This flowchart shows the complete customer lifecycle from initial inquiry to order completion.

flowchart TD
    Start([Customer Inquiry]) --> CreateLead[Create Lead]
    CreateLead --> QualifyLead{Qualify Lead?}
    
    QualifyLead -->|Yes| CreateClient[Create Client]
    QualifyLead -->|No| FollowUp[Schedule Follow-up]
    
    CreateClient --> CreateQuote[Create Quote]
    CreateQuote --> SendQuote[Send Quote to Client]
    SendQuote --> QuoteResponse{Quote Response?}
    
    QuoteResponse -->|Accepted| CreateOrder[Create Order]
    QuoteResponse -->|Rejected| ReviseQuote[Revise Quote]
    QuoteResponse -->|No Response| FollowUpQuote[Follow-up Quote]
    
    ReviseQuote --> SendQuote
    FollowUpQuote --> QuoteResponse
    
    CreateOrder --> ProcessPayment{Process Payment}
    ProcessPayment -->|Success| FulfillOrder[Fulfill Order]
    ProcessPayment -->|Failed| PaymentRetry[Retry Payment]
    
    PaymentRetry --> ProcessPayment
    
    FulfillOrder --> ShipOrder[Ship Order]
    ShipOrder --> DeliveryConfirm{Delivery Confirmed?}
    
    DeliveryConfirm -->|Yes| CreateInvoice[Create Invoice]
    DeliveryConfirm -->|No| TrackShipment[Track Shipment]
    
    TrackShipment --> DeliveryConfirm
    
    CreateInvoice --> SendInvoice[Send Invoice]
    SendInvoice --> PaymentReceived{Payment Received?}
    
    PaymentReceived -->|Yes| CloseOrder[Close Order]
    PaymentReceived -->|No| PaymentReminder[Payment Reminder]
    
    PaymentReminder --> PaymentReceived
    CloseOrder --> CustomerSatisfaction[Customer Satisfaction Survey]
    CustomerSatisfaction --> End([Process Complete])
    
    FollowUp --> CreateLead

    style Start fill:#e8f5e8
    style End fill:#e8f5e8
    style CreateOrder fill:#e1f5fe
    style ProcessPayment fill:#fff3e0
    style CreateInvoice fill:#f3e5f5

Process Stages

Lead Generation: Capture and qualify potential customers
Client Conversion: Convert qualified leads to active clients
Quote Management: Create, send, and manage quotes
Order Processing: Handle order creation and payment processing
Fulfillment: Manage shipping and delivery confirmation
Invoicing: Generate and track invoice payments
Customer Service: Ensure customer satisfaction and completion

Database Schema Relationships

This entity relationship diagram shows the core database structure and relationships between entities.

erDiagram
    TENANT ||--o{ SITE : has
    TENANT ||--o{ USER : belongs_to
    TENANT ||--o{ CLIENT : belongs_to
    TENANT ||--o{ VENDOR : has
    
    SITE ||--o{ USER : assigned_to
    SITE ||--o{ CLIENT : located_at
    SITE ||--o{ ORDER : processed_at
    SITE ||--o{ PRODUCT : available_at
    
    USER ||--o{ ORDER : creates
    USER ||--o{ CONTACT : manages
    USER }o--|| ROLE : has
    
    CLIENT ||--o{ ORDER : places
    CLIENT ||--o{ CONTACT : has
    CLIENT ||--o{ ADDRESS : has
    
    ORDER ||--o{ ORDER_ITEM : contains
    ORDER }o--|| CLIENT : placed_by
    ORDER }o--|| VENDOR : supplied_by
    
    PRODUCT ||--o{ ORDER_ITEM : included_in
    PRODUCT }o--|| VENDOR : supplied_by
    PRODUCT }o--|| CATEGORY : belongs_to
    
    VENDOR ||--o{ PRODUCT : supplies
    VENDOR ||--o{ ORDER : fulfills
    
    ROLE ||--o{ PERMISSION : grants
    
    TENANT {
        string id PK
        string name
        string slug
        string status
        json settings
        timestamp created_at
        timestamp updated_at
    }
    
    SITE {
        string id PK
        string tenant_id FK
        string name
        string description
        string status
        json data
        timestamp created_at
    }
    
    USER {
        string id PK
        string tenant_id FK
        string site_id FK
        string email
        string name
        string role_id FK
        boolean blocked
        timestamp created_at
    }
    
    CLIENT {
        string id PK
        string tenant_id FK
        string site_id FK
        string name
        string email
        string phone
        boolean archived
        timestamp created_at
    }
    
    ORDER {
        string id PK
        string tenant_id FK
        string site_id FK
        string client_id FK
        string vendor_id FK
        string invoice_number
        decimal total_amount
        string currency
        string status
        timestamp invoice_date
        timestamp created_at
    }
    
    PRODUCT {
        string id PK
        string tenant_id FK
        string site_id FK
        string vendor_id FK
        string name
        string reference
        decimal price
        integer quantity
        string type
        boolean active
    }
    
    VENDOR {
        string id PK
        string tenant_id FK
        string site_id FK
        string name
        string email
        string contact
        boolean auto_send
        json order_settings
    }

Schema Design Principles

Multi-Tenant Isolation: Every entity includes tenant_id for data isolation
Site-Based Organization: Entities are organized by sites within tenants
Flexible JSON Fields: Configuration and settings stored as JSON for flexibility
Audit Trail: Timestamps for creation and updates on all entities
Referential Integrity: Foreign key relationships ensure data consistency

Detailed UML Documentation

For comprehensive business process diagrams organized by domain, see the UML Documentation Hub:

By Domain

E-Commerce - Orders, payments, shipping, inventory
Subscriptions - Lifecycle, billing cycles, renewals
CRM - Leads, opportunities, client onboarding
CMS - Content workflow, magazine production
Communications - Email automation, delivery tracking
Workflows - Execution engine, node types, job processing
Field Service - Interventions, equipment lifecycle
Events - Bookings, availability management
POS - Transactions, kitchen display, table management
Platform - Tenant isolation, permissions, service registry

Next Steps

These diagrams provide a comprehensive overview of the Company Manager architecture. For specific implementation details, refer to:

Environment Setup for local development
Multi-Tenant Features for tenant implementation
Main Application Guide for application specifics
Database Package for schema details

Architecture Diagrams

On this page