Genius Tracker Architecture

3.1 Server Environment

Component	Specification
Operating System	Windows Server 2012 Standard Edition
Web Server	Apache 2.4.12
PHP Version	5.6.8
Database	MySQL with master-slave replication
Security	OpenSSL 1.0.1l

3.2 Framework & Languages

Category	Technologies
Backend Framework	PHP Zend Framework
Frontend	HTML, CSS, JavaScript
Admin Dashboard	Metronic Responsive Admin Dashboard

4.1 System-Level Organization

[Root]
├── gt_common/          # Shared resources and code
├── gt_master_server/   # Master server components
└── gt_slave_server/    # Slave server components

4.2 Slave Server Structure

gt_slave_server/
├── application/        # Core application code (controllers, models, etc.)
├── helpers/            # Helper classes and functions
├── library/            # Common libraries
├── public/             # Public web assets (original)
├── publicv01/          # Public web assets (current version)
└── templates/          # View templates

5.1 Master-Slave Configuration

The application utilizes a master-slave database architecture to optimize performance and reliability:

• Master Database: Primary database that handles all write operations
• Slave Database(s): Read-only replicas that distribute read load
• Replication Method: Asynchronous replication

This architecture supports the multi-tenant structure of the application, where different clients access their own isolated areas within the system.

Implementation Details:

• Separate MySQL database instances for master and slave
• Master database configured with binary logging enabled
• Slave databases set up with relay logs to capture changes from the master
• Replication user accounts with appropriate permissions

5.2 Data Flow

Genius Tracker Client Request Flow:

1. Users initially access https://genius-tracker.de/customer_area/EN/login
2. After authentication, they're directed to their client-specific area: https://genius-tracker.de/[client_id]/EN/home
3. The Genius Tracker application identifies the client context from the URL segment

Replication Process:

1. Changes made to the master database are recorded in binary logs
2. Slave databases pull these binary logs at regular intervals
3. Slave databases replay transactions to maintain data consistency
4. The application monitors replication lag to ensure data integrity

5.3 Multi-Tenant Database Structure

The database architecture supports multiple clients (tenants) within the same application:

Client Isolation:

• Client data is separated through a logical partitioning scheme
• Each client is identified by a unique client_id
• Database queries include client_id filtering to ensure data isolation

URL-Based Client Identification:

• Client context is determined from URL structure: /[client_id]/EN/...
• This client identifier is used to filter database queries appropriately
• Session management maintains the client context throughout user interaction

6.1 MVC Implementation

The application follows the Model-View-Controller (MVC) architectural pattern:

• Models: Data structures and business logic
• Views: User interface elements (templates)
• Controllers: Request handling and application flow

6.2 Entry Points

• Main application entry through the public/publicv01 index.php files
• Routing handled by Zend Framework router

7.1 Authentication & Authorization

• Login system for user authentication
• Role-based access control for authorization

7.2 Data Protection

• SSL/TLS encryption for data in transit
• Data validation and sanitization

8.1 Required Software

• PHP 5.6.8
• MySQL
• Apache 2.4.x

9.1 Deployment Steps

• Code migration process
• Database update procedures

9.2 Rollback Procedures

• Steps for reverting to previous versions
• Database rollback process

10.1 Backup Strategy

• Regular database backups
• Code repository backups

10.2 Monitoring

• Performance monitoring
• Error logging and handling