System Architecture

This document describes the complete architecture of the FT Services platform, including deployment strategy, component interactions, and infrastructure design.

Overview

FT Services is a microservices-based telecommunications platform deployed on Kubernetes (K3s) using a GitOps approach with ArgoCD and Helm.

The architecture supports multiple database backends (MySQL and Oracle) through an abstraction layer, allowing seamless switching between environments.

High-Level Architecture

FT Services Platform Architecture
Figure 1. FT Services Platform Architecture

Component Layers

1. Ingress Layer

Component: Traefik IngressRoute

Responsibilities:

  • SSL/TLS termination

  • Request routing to services

  • Rate limiting and security headers

  • Load balancing

Configuration:

ingress:
  className: traefik
  hosts:
    ftacs: "${environment}.rd.friendly-tech.com"
    uiBackend: "${environment}-api.rd.friendly-tech.com"
    portals: "${environment}-ui.rd.friendly-tech.com"

2. Frontend Layer

UI Portals

  • Technology: Angular

  • Purpose: Web interface for end users

  • Ports: 80 (HTTP), 443 (HTTPS)

  • Dependencies: UI Backend

UI AI Agent

  • Technology: Python/FastAPI

  • Purpose: AI-powered assistance

  • Database: PostgreSQL

  • External API: Google Gemini

3. API Layer

UI Backend

  • Technology: Java/Spring Boot

  • Purpose: Main API gateway

  • Port: 8880

  • Dependencies: FTACS, Main DB

Northbound API

  • Technology: Java/Spring Boot

  • Purpose: External integration API

  • Port: 8082

  • Protocol: SOAP/REST

Service API

  • Technology: Java/Spring Boot

  • Purpose: Service management operations

  • Port: 8083

Provision API

  • Technology: Java/Spring Boot

  • Purpose: Provisioning portal

  • Port: 8084

  • Additional: Flowable workflow engine

4. Core Services

FTACS (TR-069 ACS Server)

  • Technology: Java/Spring

  • Purpose: TR-069 Auto Configuration Server

  • Port: 8080

  • Protocols: TR-069 (CWMP), USP

  • Critical Component: Yes

FTACS is the core service managing CPE devices. All other services depend on it.
FTACS Component Details
Figure 2. FTACS Component Details

FT Device Network Service

  • Technology: Java/Spring Boot

  • Purpose: WiFi network management

  • Port: 8383

5. Data Layer

Main Database (MySQL/Oracle)

Aspect MySQL Oracle

Version

8.4.6

XE 21

Usage

Development

Development & Production

Storage

10-20 GB

20-50 GB

Resources

1-2 GB RAM

2-8 GB RAM

Schema

Same across both

Same across both

Database Abstraction:

The platform uses Helm template helpers to abstract database selection:

{{- define "ft-services.dbJdbcUrl" -}}
{{- if eq .Values.database.type "mysql" -}}
jdbc:mysql://mysql:3306/{{ .Values.mysql.database }}
{{- else if eq .Values.database.type "oracle" -}}
jdbc:oracle:thin:@oracle:1521/{{ .Values.oracle.serviceName }}
{{- end -}}
{{- end }}

See ADR-001 for rationale.

PostgreSQL

  • Purpose: AI Agent data storage

  • Version: 16

  • Database: ftl_ai

  • Storage: 3 GB

ClickHouse

  • Purpose: Analytics and reporting

  • Version: 24.8

  • Storage: 20 GB

  • Access: Via JDBC Bridge

6. Infrastructure Services

Hazelcast

  • Purpose: Distributed caching

  • Version: 5.5.0

  • Mode: In-memory data grid

  • Replicas: 1 (dev), 3 (prod)

JDBC Bridge

  • Purpose: Connect ClickHouse to MySQL/Oracle

  • Technology: Custom JDBC connector

Prometheus

  • Purpose: Metrics collection

  • Scrape Interval: 30s

  • Retention: 15d

Grafana

  • Purpose: Metrics visualization

  • Data Sources: Prometheus, Loki

Loki

  • Purpose: Log aggregation

  • Retention: 7-30d (environment-dependent)

Deployment Architecture

GitOps Flow

GitOps Deployment Flow
Figure 3. GitOps Deployment Flow

Environment Strategy

Environment Purpose Namespace ArgoCD App

dev

Daily development

dev

dev-mysql

dev-oracle

Oracle testing

dev-oracle

dev-oracle

feature-*

Feature branches

feature-*

Dynamic

main

Production

production

main
Multi-Environment Deployment
@startuml
skinparam backgroundColor transparent

package "Git Repository" {
    [values.yaml] as base
    [values-dev-mysql.yaml] as dev
    [values-dev-oracle.yaml] as oracle
    [values-main.yaml] as main
}

package "ArgoCD Applications" {
    [dev-mysql app] as devapp
    [dev-oracle app] as oracleapp
    [main app] as mainapp
}

package "K3s Cluster" {
    namespace "dev" {
        [Services] as devsvcs
        [MySQL] as devdb
    }

    namespace "dev-oracle" {
        [Services] as oraclesvcs
        [Oracle] as oracledb
    }

    namespace "production" {
        [Services] as mainsvcs
        [Oracle] as maindb
    }
}

base --> dev
base --> oracle
base --> main

dev --> devapp
oracle --> oracleapp
main --> mainapp

devapp --> devsvcs
devapp --> devdb

oracleapp --> oraclesvcs
oracleapp --> oracledb

mainapp --> mainsvcs
mainapp --> maindb

@enduml

Network Architecture

Service Communication

Internal Service Communication
Figure 4. Internal Service Communication

Network Policies

Network policies implement zero-trust networking with explicit allow rules.

Key policies:

  • default-deny-all - Blocks all traffic by default

  • allow-dns - Permits DNS resolution

  • ftacs-policy - FTACS communication rules

  • database-policy - Database access restrictions

External Access

External Access via Ingress
Figure 5. External Access via Ingress

Storage Architecture

Persistent Volumes

Service Purpose Size Type

MySQL

Database files

10-20 GB

RWO

Oracle

Database files

20-50 GB

RWO

ClickHouse

Analytics data

20 GB

RWO

Hazelcast

Persistent cache

1 GB

RWO

Loki

Log storage

50 GB

RWO

Prometheus

Metrics storage

10 GB

RWO

MySQL Backups

Database backups

50 GB

RWO

Backup Strategy

Component Backup Method Frequency Retention

MySQL

mysqldump

Daily 2 AM

7 days

Oracle

RMAN

Daily 2 AM

14 days

Persistent Volumes

Velero snapshots

Daily

30 days

Application State

ArgoCD sync

Continuous

Git history

Scaling Architecture

Horizontal Scaling

Services supporting HPA (Horizontal Pod Autoscaling):

  • UI Backend

  • Northbound API

  • Service API

  • Provision API

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ui-backend
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ui-backend
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Vertical Scaling

Resource profiles defined per environment:

Profile CPU Request Memory Request Use Case

small

100m

256Mi

Feature branches

medium

500m

1Gi

Development

large

2000m

4Gi

Production

Security Architecture

Authentication & Authorization

  • Ingress: Traefik with SSL/TLS termination

  • Services: Basic authentication or OAuth2 (configurable)

  • Database: Sealed Secrets for credentials

  • Registry: Harbor with role-based access

Secret Management

Secret Management Flow
Figure 6. Secret Management Flow

Network Security

  • Network Policies for pod-to-pod communication

  • Ingress rate limiting

  • Security headers (XSS, CSP, HSTS)

  • No exposed database ports externally

Monitoring Architecture

Metrics Collection

Monitoring Stack
Figure 7. Monitoring Stack

Key metrics:

  • Service availability

  • Response times (p50, p95, p99)

  • Error rates

  • Resource usage (CPU, memory)

  • Database query performance

Logging Architecture

Logging Stack
Figure 8. Logging Stack

See Logging Configuration for details.

Disaster Recovery

Key recovery points:

  • RTO (Recovery Time Objective): 4 hours

  • RPO (Recovery Point Objective): 1 hour

See Disaster Recovery Runbook for procedures.

Related Documentation

Last updated: 2026-08-08 10:57:08 +0200