Files
lcbp3/specs/02-architecture/system-architecture.md
admin ec35521258
Some checks failed
Spec Validation / validate-markdown (push) Has been cancelled
Spec Validation / validate-diagrams (push) Has been cancelled
Spec Validation / check-todos (push) Has been cancelled
251213:1509 Docunment Number Businee Rule not correct
2025-12-13 15:09:01 +07:00

26 KiB

🏗️ System Architecture Specification


title: 'System Architecture' version: 1.5.0 status: first-draft owner: Nattanin Peancharoen last_updated: 2025-11-30 related:

  • specs/01-requirements/02-architecture.md
  • specs/01-requirements/06-non-functional.md
  • specs/03-implementation/fullftack-js-v1.5.0.md

📋 ภาพรวม (Overview)

เอกสารนี้อธิบายสถาปัตยกรรมระบบ LCBP3-DMS (Laem Chabang Port Phase 3 - Document Management System) ที่ใช้แนวทาง Headless/API-First Architecture พร้อมการ Deploy บน QNAP Server ผ่าน Container Station

🎯 Architecture Principles

1.1 Core Principles

  1. Data Integrity First: ความถูกต้องของข้อมูลต้องมาก่อนทุกอย่าง
  2. Security by Design: รักษาความปลอดภัยที่ทุกชั้น
  3. Scalability: รองรับการเติบโตในอนาคต
  4. Resilience: ทนทานต่อ Failure และ Recovery ได้รวดเร็ว
  5. Observability: ติดตามและวิเคราะห์สถานะระบบได้ง่าย

1.2 Architecture Style

  • Headless CMS Architecture: แยก Frontend และ Backend เป็นอิสระ
  • API-First: Backend เป็น API Server ที่ Frontend หรือ Third-party สามารถเรียกใช้ได้
  • Microservices-Ready: ออกแบบเป็น Modular Architecture พร้อมแยกเป็น Microservices ในอนาคต

🏢 Infrastructure & Deployment

2.1 Server Infrastructure

  • Server: QNAP TS-473A
    • CPU: AMD Ryzen V1500B
    • RAM: 32GB
    • Storage: /share/dms-data
  • IP Address: 159.192.126.103
  • Domain: np-dms.work, <www.np-dms.work>
  • Containerization: Docker & Docker Compose via Container Station
  • Development Environment: VS Code/Cursor on Windows 11

2.2 Network Architecture

graph TB
    Internet[Internet] --> NPM[Nginx Proxy Manager<br/>npm.np-dms.work]
    NPM --> Frontend[Next.js Frontend<br/>lcbp3.np-dms.work]
    NPM --> Backend[NestJS Backend<br/>backend.np-dms.work]
    NPM --> PMA[phpMyAdmin<br/>pma.np-dms.work]
    NPM --> N8N[n8n Workflow<br/>n8n.np-dms.work]
    NPM --> Gitea[Gitea Git<br/>git.np-dms.work]

    Backend --> MariaDB[(MariaDB 11.8<br/>db.np-dms.work)]
    Backend --> Redis[(Redis Cache)]
    Backend --> Elastic[Elasticsearch]
    Backend --> Storage[File Storage<br/>/share/dms-data]

    N8N --> Line[LINE Notify]
    Backend --> Email[Email Server]

Docker Network:

  • Network Name: lcbp3
  • ทุก Service เชื่อมต่อผ่าน Internal Docker Network เพื่อความปลอดภัย

2.3 Configuration Management

[!WARNING] > ข้อจำกัดสำคัญ: QNAP Container Station ไม่รองรับการใช้ .env files ในการกำหนด Environment Variables

Configuration Strategy:

  1. Production/Staging:

    • ใช้ docker-compose.yml สำหรับกำหนด Environment Variables
    • ห้ามระบุ Sensitive Secrets (Password, Keys) ใน docker-compose.yml หลัก
    • ใช้ docker-compose.override.yml (gitignored) สำหรับ Secrets
    • พิจารณาใช้ Docker Secrets หรือ Hashicorp Vault
  2. Development:

    • ใช้ docker-compose.override.yml สำหรับ Local Secrets
    • ไฟล์หลักใส่ค่า Dummy/Placeholder
  3. Validation:

    • ใช้ Joi/Zod validate Environment Variables ตอน App Start
    • Throw Error ทันทีหากขาด Variable สำคัญ

🔧 Core Services

3.1 Service Overview

Service Application Name Domain Technology Purpose
Frontend lcbp3-frontend lcbp3.np-dms.work Next.js 14+ (App Router) Web Application UI
Backend lcbp3-backend backend.np-dms.work NestJS (TypeScript) API Server & Business Logic
Database lcbp3-db db.np-dms.work MariaDB 11.8 Primary Database
DB Management lcbp3-db pma.np-dms.work phpMyAdmin Database Admin UI
Reverse Proxy lcbp3-npm npm.np-dms.work Nginx Proxy Manager Reverse Proxy & SSL
Workflow lcbp3-n8n n8n.np-dms.work n8n Workflow Automation
Git git git.np-dms.work Gitea Self-hosted Git
Cache - - Redis Caching & Locking
Search - - Elasticsearch Full-text Search

3.2 Frontend (Next.js)

Stack:

  • Framework: Next.js 14+ with App Router
  • Language: TypeScript (ESM)
  • Styling: Tailwind CSS + PostCSS
  • Components: shadcn/ui
  • State Management:
    • Server State: TanStack Query (React Query)
    • Form State: React Hook Form + Zod
    • UI State: useState/useReducer

Responsibilities:

  • Render Web UI สำหรับผู้ใช้
  • จัดการ User Interactions
  • เรียก Backend API
  • Client-side Validation
  • Responsive Design (Desktop + Mobile)

3.3 Backend (NestJS)

Stack:

  • Framework: NestJS (Node.js + TypeScript)
  • ORM: TypeORM
  • Authentication: JWT + Passport
  • Authorization: CASL (RBAC)
  • Validation: class-validator + class-transformer
  • Documentation: Swagger/OpenAPI

Responsibilities:

  • ให้บริการ RESTful API
  • Business Logic Processing
  • Authentication & Authorization
  • Data Validation
  • Database Operations
  • File Upload Handling (Two-Phase Storage)
  • Workflow Engine
  • Background Jobs (Notifications, Cleanup)

3.4 Database (MariaDB 11.8)

Features:

  • JSON Support: จัดเก็บ details fields (Dynamic Schema)
  • Virtual Columns: Index JSON fields สำหรับ Performance
  • Partitioning: สำหรับ audit_logs และ notifications
  • Optimistic Locking: ใช้ @VersionColumn() ป้องกัน Race Condition

Key Tables:

  • Users & Permissions: users, roles, permissions, user_roles
  • Projects: projects, organizations, contracts, project_parties
  • Documents: correspondences, rfas, shop_drawings, contract_drawings
  • Workflow: workflow_definitions, workflow_instances, workflow_history
  • Files: attachments, correspondence_attachments, etc.
  • Audit: audit_logs

3.5 Redis

Use Cases:

  1. Distributed Locking: Document Numbering, Critical Operations
  2. Session Caching: User Permissions, Profile Data
  3. Master Data Cache: Roles, Permissions, Organizations (TTL: 1 hour)
  4. Queue Management: BullMQ for Background Jobs
  5. Rate Limiting: Track API Request Counts

3.6 Elasticsearch

Use Cases:

  • Full-text Search: Search across Correspondence, RFA, Drawings
  • Advanced Filtering: Multi-criteria Search
  • Aggregations: Statistics และ Dashboard Data

Indexing Strategy:

  • Index อัตโนมัติเมื่อ Create/Update เอกสาร
  • Async Indexing ผ่าน Queue (ไม่ Block Main Request)

🧱 Backend Module Architecture

4.1 Modular Design

graph TB
    subgraph "Core Modules"
        Common[CommonModule<br/>Shared Services]
        Auth[AuthModule<br/>JWT & Guards]
        User[UserModule<br/>User Management]
    end

    subgraph "Business Modules"
        Project[ProjectModule<br/>Projects & Contracts]
        Corr[CorrespondenceModule<br/>Correspondences]
        RFA[RfaModule<br/>RFA Management]
        Drawing[DrawingModule<br/>Shop & Contract Drawings]
        Circ[CirculationModule<br/>Circulation Sheets]
        Trans[TransmittalModule<br/>Transmittals]
    end

    subgraph "Supporting Modules"
        Workflow[WorkflowEngineModule<br/>Unified Workflow]
        Numbering[DocumentNumberingModule<br/>Auto Numbering]
        Search[SearchModule<br/>Elasticsearch]
        Master[MasterModule<br/>Master Data]
        JSON[JsonSchemaModule<br/>JSON Validation]
    end

    Corr --> Workflow
    RFA --> Workflow
    Circ --> Workflow

    Corr --> Numbering
    RFA --> Numbering

    Search --> Corr
    Search --> RFA
    Search --> Drawing

4.2 Module Descriptions

4.2.1 CommonModule

Responsibilities:

  • Database Configuration
  • FileStorageService (Two-Phase Upload)
  • AuditLogService
  • NotificationService
  • Shared DTOs, Guards, Interceptors

4.2.2 AuthModule

Responsibilities:

  • JWT Token Management
  • Authentication Guards
  • 4-Level Permission Checking:
    • Global (Superadmin)
    • Organization
    • Project
    • Contract
  • Token Refresh & Revocation

4.2.3 UserModule

Responsibilities:

  • User CRUD Operations
  • Role Assignment
  • Permission Management
  • User Profile Management

4.2.4 ProjectModule

Responsibilities:

  • Project Management
  • Contract Management
  • Organization Management
  • Project Parties & Contract Parties

4.2.5 CorrespondenceModule

Responsibilities:

  • Correspondence CRUD
  • Revision Management
  • Attachment Handling
  • Workflow Integration (Routing)

4.2.6 RfaModule

Responsibilities:

  • RFA CRUD
  • RFA Item Management
  • Workflow Integration (Approval Process)
  • Respond/Approve Actions

4.2.7 DrawingModule

Responsibilities:

  • Shop Drawing Management
  • Contract Drawing Management
  • Drawing Categories
  • Revision Tracking
  • Drawing References

4.2.8 CirculationModule

Responsibilities:

  • Circulation Sheet Management
  • Circulation Templates
  • Assignees Management
  • Workflow Integration (Internal Circulation)

4.2.9 WorkflowEngineModule (Core)

[!IMPORTANT] > Unified Workflow Engine - ระบบกลางสำหรับจัดการ Workflow ทั้งหมด

Features:

  • DSL-Based Workflow Definitions (JSON Configuration)
  • State Machine Management
  • Workflow Instance Tracking
  • History & Audit Trail
  • Workflow Versioning

Entities:

  • WorkflowDefinition: กำหนด Workflow Template
  • WorkflowInstance: Instance ที่กำลังรัน
  • WorkflowHistory: ประวัติการเปลี่ยน State

Integration:

  • CorrespondenceModule → Routing Workflow
  • RfaModule → Approval Workflow
  • CirculationModule → Internal Circulation Workflow

4.2.10 DocumentNumberingModule (Internal)

Responsibilities:

  • Auto-generate Document Numbers
  • Token-Based Generator: {CONTRACT}-{TYPE}-{DISCIPLINE}-{SEQ:4}
  • Double-Lock Mechanism:
    • Layer 1: Redis Distributed Lock
    • Layer 2: Optimistic Database Lock (@VersionColumn())

Algorithm:

  1. Parse Template → Identify Required Tokens
  2. Acquire Redis Lock (Key: project_id:type_id:discipline_id:year)
  3. Query document_number_counters Table
  4. Increment Counter (Check Version)
  5. Generate Final Number
  6. Release Lock
  7. Retry on Conflict (Exponential Backoff)

4.2.11 SearchModule

Responsibilities:

  • Elasticsearch Integration
  • Full-text Search across Documents
  • Advanced Filtering
  • Search Result Aggregation

4.2.12 JsonSchemaModule (Internal)

Responsibilities:

  • JSON Schema Validation (AJV)
  • Schema Versioning & Migration
  • Dynamic Schema Generation
  • Data Transformation

📊 Data Flow Architecture

5.1 Main Request Flow

sequenceDiagram
    participant Client as Client (Browser)
    participant NPM as Nginx Proxy
    participant BE as Backend (NestJS)
    participant Redis as Redis Cache
    participant DB as MariaDB
    participant ES as Elasticsearch

    Client->>NPM: HTTP Request + JWT
    NPM->>BE: Forward Request

    BE->>BE: Rate Limit Check
    BE->>BE: Validate Input (DTO)
    BE->>BE: JWT Auth Guard
    BE->>Redis: Get User Permissions
    Redis-->>BE: Permission Data
    BE->>BE: RBAC Guard (Check Permission)

    BE->>DB: Query Data
    DB-->>BE: Return Data

    BE->>BE: Business Logic Processing
    BE->>DB: Save Changes (Transaction)
    BE->>ES: Index for Search
    BE->>Redis: Invalidate Cache

    BE->>DB: Audit Log
    BE-->>Client: JSON Response

5.2 File Upload Flow (Two-Phase Storage)

[!IMPORTANT] > Two-Phase Storage ป้องกัน Orphan Files และรักษา Data Integrity

sequenceDiagram
    participant Client
    participant Backend
    participant ClamAV as Virus Scanner
    participant TempStorage as Temp Storage
    participant PermStorage as Permanent Storage
    participant DB as Database

    Client->>Backend: Upload File
    Backend->>ClamAV: Scan Virus
    ClamAV-->>Backend: Scan Result (CLEAN/INFECTED)

    alt File is CLEAN
        Backend->>TempStorage: Save to temp/
        Backend-->>Client: Return temp_id

        Client->>Backend: POST Create Document (include temp_id)
        Backend->>DB: BEGIN Transaction
        Backend->>DB: Create Document Record
        Backend->>PermStorage: Move temp/ → permanent/{YYYY}/{MM}/
        Backend->>DB: Create Attachment Record
        Backend->>DB: COMMIT Transaction
        Backend-->>Client: Success Response
    else File is INFECTED
        Backend-->>Client: Error: Virus Detected
    end

    Note over Backend,TempStorage: Cron Job: Delete temp files > 24h

5.3 Document Numbering Flow

sequenceDiagram
    participant Service as Correspondence Service
    participant Numbering as Numbering Service
    participant Redis
    participant DB as MariaDB

    Service->>Numbering: generateNextNumber(context)
    Numbering->>Numbering: Parse Template
    Numbering->>Redis: ACQUIRE Lock (project:type:year)

    alt Lock Acquired
        Redis-->>Numbering: Lock Success
        Numbering->>DB: SELECT counter (with version)
        DB-->>Numbering: current_number, version
        Numbering->>DB: UPDATE counter SET last_number = X, version = version + 1 WHERE version = old_version

        alt Update Success
            DB-->>Numbering: Success
            Numbering->>Numbering: Generate Final Number
            Numbering->>Redis: RELEASE Lock
            Numbering-->>Service: Document Number
        else Version Conflict (Race Condition)
            DB-->>Numbering: Update Failed
            Numbering->>Redis: RELEASE Lock
            Numbering->>Numbering: Retry (Exponential Backoff)
        end
    else Lock Failed
        Redis-->>Numbering: Lock Timeout
        Numbering->>Numbering: Retry or Fail
    end

5.4 Workflow Execution Flow

sequenceDiagram
    participant User
    participant Module as Correspondence Module
    participant Engine as Workflow Engine
    participant DB
    participant Notify as Notification Service

    User->>Module: Create Correspondence
    Module->>Engine: createWorkflowInstance(definition_id, entity_id)
    Engine->>DB: Create workflow_instance
    Engine->>DB: Set initial state
    Engine-->>Module: Instance Created
    Module-->>User: Success

    User->>Module: Execute Action (e.g., "Send")
    Module->>Engine: executeTransition(instance_id, action)
    Engine->>DB: Check current state
    Engine->>Engine: Validate transition (DSL)

    alt Transition Valid
        Engine->>DB: Update state
        Engine->>DB: Create workflow_history
        Engine->>Notify: Trigger Notification
        Notify->>Notify: Queue Email/Line
        Engine-->>Module: Transition Success
        Module-->>User: Action Completed
    else Invalid Transition
        Engine-->>Module: Error: Invalid State Transition
        Module-->>User: Error Response
    end

🛡️ Security Architecture

6.1 Security Layers

graph TB
    subgraph "Layer 1: Network Security"
        SSL[SSL/TLS<br/>Nginx Proxy Manager]
        Firewall[Firewall Rules<br/>QNAP]
    end

    subgraph "Layer 2: Application Security"
        RateLimit[Rate Limiting]
        CSRF[CSRF Protection]
        XSS[XSS Prevention]
        Input[Input Validation]
    end

    subgraph "Layer 3: Authentication"
        JWT[JWT Tokens]
        Refresh[Token Refresh]
        Revoke[Token Revocation]
    end

    subgraph "Layer 4: Authorization"
        RBAC[4-Level RBAC]
        Guards[Permission Guards]
        CASL[CASL Rules]
    end

    subgraph "Layer 5: Data Security"
        Encrypt[Data Encryption]
        Audit[Audit Logs]
        Backup[Backups]
    end

    subgraph "Layer 6: File Security"
        Virus[Virus Scanning]
        FileType[Type Validation]
        FileAccess[Access Control]
    end

6.2 Authentication & Authorization Details

JWT Token Structure:

{
  "sub": "user_id",
  "scope": "organization_id|project_id|contract_id",
  "iat": 1638360000,
  "exp": 1638388800
}

Permission Checking Logic:

  1. Extract JWT from Authorization: Bearer <token>
  2. Validate Token (Signature, Expiration)
  3. Get User Permissions from Redis Cache (Key: user:{user_id}:permissions)
  4. Check Permission based on Context:
    • Global Permission (Superadmin)
    • Organization Permission
    • Project Permission (if in project context)
    • Contract Permission (if in contract context)
  5. Allow if any level grants permission (Most Permissive)

6.3 Rate Limiting

Endpoint Category Limit Tracking
Anonymous 100 req/hour IP Address
Authentication 10 req/min IP Address
File Upload 50 req/hour User ID
Search 500 req/hour User ID
Viewer 500 req/hour User ID
Editor 1000 req/hour User ID
Document Control 2000 req/hour User ID
Admin 5000 req/hour User ID

Implementation: rate-limiter-flexible library with Redis backend

6.4 Input Validation

Frontend (Client-Side):

  • React Hook Form + Zod Schema Validation
  • Sanitize User Inputs before Display

Backend (Server-Side):

  • class-validator DTOs
  • Whitelist Validation (@ValidateIf, @IsEnum, etc.)
  • Transform Pipes

File Upload Validation:

  1. File Type Validation:

    • White-list: PDF, DWG, DOCX, XLSX, ZIP
    • Magic Number Verification (ไม่ใช่แค่ extension)
  2. File Size Validation:

    • Maximum: 50MB per file
  3. Virus Scanning:

    • ClamAV Integration
    • Scan before saving to temp storage

6.5 OWASP Top 10 Protection

Vulnerability Protection Measure
SQL Injection Parameterized Queries (TypeORM)
XSS Input Sanitization + Output Encoding
CSRF CSRF Tokens (State-changing ops)
Broken Auth JWT + Secure Token Management
Security Misconfiguration Security Headers (Helmet.js)
Sensitive Data Exposure Encryption + Secure Storage
Insufficient Logging Comprehensive Audit Logs
Insecure Deserialization Input Validation
Using Known Vulnerable Components Regular Dependency Updates

📈 Performance & Scalability

7.1 Caching Strategy

Data Type Cache Location TTL Invalidation
User Permissions Redis 30 min On role/permission change
Master Data Redis 1 hour On update
Search Results Redis 15 min Time-based
File Metadata Redis 1 hour On file update
Session Data Redis 8 hours On logout

7.2 Database Optimization

Indexes:

  • Foreign Keys (Auto-indexed)
  • Search Columns (idx_cor_project, idx_rfa_status, etc.)
  • JSON Virtual Columns (for frequently queried JSON fields)

Partitioning:

  • audit_logs: Partitioned by Year
  • notifications: Partitioned by Month
  • Automated Partition Creation (Cron Job)

Query Optimization:

  • Use Views for Complex Queries (v_current_correspondences, v_user_tasks)
  • Pagination for Large Datasets
  • Eager/Lazy Loading Strategy

7.3 Performance Targets

Metric Target Measurement
API Response Time (90th percentile) < 200ms Simple CRUD
Search Query Performance < 500ms Complex Search
File Upload Processing < 30s 50MB file
Concurrent Users 100+ Simultaneous
Cache Hit Ratio > 80% Master Data
Application Startup < 30s Cold Start

🔄 Resilience & Error Handling

8.1 Resilience Patterns

Circuit Breaker:

  • Applied to: Elasticsearch, Email Service, LINE Notify
  • Threshold: 5 failures in 1 minute
  • Timeout: 30 seconds
  • Recovery: Half-open after 1 minute

Retry Mechanism:

  • Strategy: Exponential Backoff
  • Max Retries: 3
  • Applied to: External API Calls, Document Numbering

Graceful Degradation:

  • Search Service Down → Return cached results or basic search
  • Email Service Down → Queue for later retry
  • LINE Notify Down → Log error, continue operation

8.2 Error Handling

Backend:

  • Global Exception Filter
  • Structured Error Response Format
  • Error Logging with Context (Winston)
  • Don't Expose Internal Details in Error Messages

Frontend:

  • Error Boundaries (React)
  • Toast Notifications
  • Fallback UI Components
  • Retry Mechanisms for Failed Requests

📊 Monitoring & Observability

9.1 Health Checks

Endpoints:

GET /health          # Overall health
GET /health/ready    # Readiness probe
GET /health/live     # Liveness probe

Checks:

  • Database Connection
  • Redis Connection
  • Elasticsearch Connection
  • Disk Space
  • Memory Usage

9.2 Metrics Collection

Application Metrics:

  • Request Rate (req/sec)
  • Response Time (p50, p90, p99)
  • Error Rate
  • Active Connections

Business Metrics:

  • Documents Created per Day
  • Workflow Completion Rate
  • User Activity
  • Search Query Performance

Infrastructure Metrics:

  • CPU Usage
  • Memory Usage
  • Disk I/O
  • Network Throughput

9.3 Logging Strategy

[!WARNING] > QNAP Storage Constraints: ต้องจำกัดปริมาณ Logs

Log Levels:

  • Production: WARN and ERROR only
  • Staging: INFO for critical business flows
  • Development: DEBUG allowed

Structured Logging:

{
  "timestamp": "2025-11-30T13:48:20Z",
  "level": "INFO",
  "service": "backend",
  "module": "CorrespondenceModule",
  "action": "create",
  "user_id": 1,
  "ip_address": "192.168.1.100",
  "duration_ms": 45,
  "message": "Correspondence created successfully"
}

Log Rotation:

  • Rotate Daily
  • Keep 7 days
  • Compress Old Logs

9.4 Audit Logging

Scope:

  • All CRUD Operations on Critical Data
  • Permission Changes
  • Login Attempts (Success/Failure)
  • File Downloads
  • Workflow State Changes

Audit Log Fields:

  • user_id
  • action (e.g., correspondence.create)
  • entity_type, entity_id
  • old_values, new_values (for updates)
  • ip_address, user_agent
  • timestamp

💾 Backup & Disaster Recovery

10.1 Backup Strategy

Database Backup:

  • Frequency: Daily (Automated)
  • Method: Full Backup + Transaction Logs
  • Retention: 30 days
  • Tool: QNAP HBS 3 or mysqldump

File Storage Backup:

  • Frequency: Daily
  • Path: /share/dms-data
  • Method: Incremental Backup
  • Retention: 30 days
  • Tool: QNAP Snapshot or rsync

10.2 Disaster Recovery

Recovery Objectives:

  • RTO (Recovery Time Objective): < 4 hours
  • RPO (Recovery Point Objective): < 1 hour

Recovery Procedures:

  1. Database Restoration:

    • Restore latest full backup
    • Apply transaction logs to point-in-time
    • Verify data integrity
  2. File Storage Restoration:

    • Restore from QNAP snapshot
    • Verify file permissions
  3. Application Redeployment:

    • Deploy from known-good Docker images
    • Verify health checks
  4. Data Integrity Verification:

    • Run consistency checks
    • Verify critical business data

🏗️ Deployment Architecture

11.1 Container Deployment

Docker Compose Services:

services:
  frontend:
    image: lcbp3-frontend:latest
    networks: [lcbp3]
    depends_on: [backend]

  backend:
    image: lcbp3-backend:latest
    networks: [lcbp3]
    depends_on: [mariadb, redis, elasticsearch]

  mariadb:
    image: mariadb:10.11
    networks: [lcbp3]
    volumes: [/share/dms-data/mysql:/var/lib/mysql]

  redis:
    image: redis:7-alpine
    networks: [lcbp3]

  elasticsearch:
    image: elasticsearch:8.x
    networks: [lcbp3]

  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    networks: [lcbp3]
    ports: [80:80, 443:443]

11.2 CI/CD Pipeline (Future)

graph LR
    Git[Gitea Repository] --> Build[Build & Test]
    Build --> StagingDeploy[Deploy to Staging]
    StagingDeploy --> Test[Run E2E Tests]
    Test --> Manual[Manual Approval]
    Manual --> ProdDeploy[Deploy to Production]
    ProdDeploy --> Monitor[Monitor & Alert]

🎯 Future Enhancements

12.1 Scalability Improvements

  • Separate into Microservices (when needed)
  • Add Load Balancer (HAProxy/Nginx)
  • Database Replication (Master-Slave)
  • Message Queue (RabbitMQ/Kafka) for async processing

12.2 Advanced Features

  • AI-Powered Document Classification
  • Advanced Analytics & Reporting
  • Mobile Native Apps
  • Blockchain Integration for Document Integrity

12.3 Infrastructure

  • Multi-Region Deployment
  • CDN for Static Assets
  • Automated Failover
  • Blue-Green Deployment

Document Control:

  • Version: 1.6.0
  • Status: Active
  • Last Updated: 2025-12-13
  • Owner: Nattanin Peancharoen