Update ONPREM_ARCHITECTURE.md

This commit is contained in:
2026-03-16 10:24:00 -05:00
parent 42218e233c
commit 78e4c4dda3

224
ONPREM_ARCHITECTURE.md Normal file
View File

@@ -0,0 +1,224 @@
# 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**.