# On-Premises System Architecture ## Overview This document describes the architecture for the **on-premises deployment of the application system**. The system is hosted entirely within the company's internal infrastructure and is **not dependent on cloud services**. The design prioritizes: * local control of infrastructure * internal network performance * simplified deployment * managed backups through **CBM Technology** High availability and cloud failover are **not included** in this architecture. --- # Architecture Overview ```mermaid flowchart TB USER[Internal Users] LAN[Company Network] APP[On Prem Application Server] DB[(Primary Database)] BACKUP[CBM Backup System] USER --> LAN LAN --> APP APP --> DB APP --> BACKUP DB --> BACKUP ``` --- # System Access The application is accessed through the **internal network**. Example: ``` http://app.local ``` or ``` http://server-name ``` Remote access may be provided through a **VPN connection**. ```mermaid flowchart LR USER[User Device] VPN[VPN Connection] LAN[Company Network] APP[Application Server] DB[(Database)] USER --> VPN VPN --> LAN LAN --> APP APP --> DB ``` --- # Infrastructure Components ## Application Server The on-premises server hosts the application software. Responsibilities include: * serving the web interface * processing application logic * connecting to the database * managing file storage if required Typical deployment: * Windows Server or Linux server * Web server (IIS, Nginx, or Apache) * Application runtime environment --- ## Database Server The database stores all operational data for the application. Examples of stored data: * inventory records * application configuration * user accounts * transaction history In smaller deployments the database may run on the **same server as the application**, though separating them can improve performance. --- # Network Layout The application resides inside the company LAN. ```mermaid flowchart TB USERS[Internal Workstations] SWITCH[Network Switch] SERVER[Application Server] DB[(Database)] USERS --> SWITCH SWITCH --> SERVER SERVER --> DB ``` Access is restricted to internal users or remote users connected via VPN. --- # Backup System Backups are managed by **CBM Technology** to protect against hardware failure, data corruption, or accidental deletion. ```mermaid flowchart LR APP[Application Server] DB[(Database)] CBM[CBM Backup Storage] APP --> CBM DB --> CBM ``` Backups typically include: * full server snapshots * database backups * file storage backups --- # Backup Schedule Typical backup configuration: | Backup Type | Frequency | | ------------------- | --------------------- | | Database Backup | Daily | | Server Snapshot | Daily | | File Storage Backup | Daily | | Retention Period | Defined by CBM policy | Backups are stored **offsite** to protect against local disasters. --- # Disaster Recovery If the system fails due to hardware issues or data corruption: 1. The affected server is repaired or replaced. 2. The most recent backup is restored by **CBM Technology**. 3. Application services are restarted. 4. Users reconnect to the system. Recovery time depends on: * server replacement time * backup restoration duration * database size --- # Limitations of This Architecture Because the system is **single-site and non-redundant**, the following events may cause downtime: | Event | Result | | ----------------------- | -------------------------------------- | | Server hardware failure | Application unavailable until restored | | Power outage | System offline | | Network switch failure | Users unable to access server | | Database corruption | Restore from backup required | --- # Potential Future Improvements If higher reliability is required, the architecture could be expanded to include: * secondary application server * database replication * network redundancy * uninterruptible power supply (UPS) * offsite disaster recovery infrastructure These additions would move the system toward a **high availability architecture**.