Kembali ke Daftar

Architecture Diagram - RLUbiodiversity.com Visual Data Platform

NOTE: This architecture document is a conceptual schema and is subject to change based on new requirements, technical constraints, or development needs. The actual implementation may differ from this initial design.

1. Overview

This document provides the architecture diagram and description of the RLUbiodiversity.com Visual Data Platform, a custom-built system that integrates with Amaturalist API to display biodiversity observation data using Three.js for 3D visualization and story maps.

1.1 System Purpose

The RLUbiodiversity.com Visual Data Platform is a specialized web application designed to:

  • Visualize biodiversity observation data from Amaturalist in 3D using Three.js
  • Create interactive story maps with geospatial data
  • Provide real-time data updates using Redis caching
  • Enable content management through admin panel
  • Store custom content (text storymaps, media) separate from Amaturalist

1.2 Key Features

  • 3D Visualization: Three.js integration for immersive data visualization
  • Story Maps: Interactive geospatial narratives
  • Real-time Updates: Redis-based caching for live data synchronization
  • API Integration: Secure token-based access to Amaturalist API
  • Content Management: Admin panel for managing custom content and media
  • Comprehensive Data: All taxa data from Amaturalist General Observations

2. System Architecture

2.1 High-Level Architecture

graph TB
    subgraph USER_LAYER["USER LAYER"]
        WEB_USER[Web Browser
RLUbiodiversity.com Visual Data Platform
Three.js + React]
        ADMIN_USER[Admin Panel
Content Management
Media Upload]
    end

    subgraph RLU_FRONTEND["RLU FRONTEND"]
        REACT[React Application
Three.js Integration
Story Maps Component]
        REDIS_CLIENT[Redis Client
Real-time Subscriptions]
    end

    subgraph CDN["CDN LAYER"]
        CF[Cloudflare CDN
Static Assets
SSL/TLS Termination]
    end

    subgraph RLU_BACKEND["RLU BACKEND"]
        API[Laravel API Routes
Middleware Layer]
        REDIS[(Redis Cache
Real-time Data
Admin Session Storage)]
        CONTENT_DB[(Content Database
Storymaps
Media Metadata)]
    end

    subgraph AMATURALIST_API["AMATURALIST API EXTERNAL"]
        AUTH[JWT Authentication
API Token Management]
        GEN_OBS[General Observations API
/api/general-observations]
    end

    subgraph AMATURALIST_BACKEND["AMATURALIST BACKEND (Existing)"]
        AMATURALIST_DB[(Amaturalist Database
Observations Data)]
        S3[(S3 Storage
Media Files)]
    end

    USER_LAYER -->|HTTPS| CDN
    CDN --> REACT
    REACT --> API
    API -->|API Token| AUTH
    AUTH --> GEN_OBS
    GEN_OBS --> AMATURALIST_DB
    AMATURALIST_DB --> S3
    API --> REDIS
    REDIS --> REACT
    ADMIN_USER --> API
    API --> CONTENT_DB

    style USER_LAYER fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style RLU_FRONTEND fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style RLU_BACKEND fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style AMATURALIST_API fill:#ca8a04,stroke:#ea580c,stroke-width:2px,color:#ffffff
    style AMATURALIST_BACKEND fill:#ca8a04,stroke:#ea580c,stroke-width:2px,color:#ffffff

2.2 Technology Stack

Frontend

  • Framework: React 18+
  • 2D Maps: Leaflet
  • 3D Maps: MapTiler
  • 3D Visualization: Three.js (non-map visualizations)
  • Styling: TailwindCSS
  • State Management: React Context + Redux Toolkit
  • Real-time: Socket.io Client
  • Build Tool: Vite

Backend

  • Framework: Laravel (Latest Stable Version)
  • Runtime: PHP 8.2+
  • Cache: Redis 7+
  • Database: MySQL / PostgreSQL
  • ORM: Laravel Eloquent
  • Real-time: Laravel Broadcasting / Pusher
  • API: Laravel API Resources

Infrastructure

  • Hosting: Exabytes VPS
  • CDN: Cloudflare
  • SSL: Let's Encrypt
  • Monitoring: Uptime Robot
  • CI/CD: GitHub Actions

3. Data Flow Architecture

3.1 Data Fetching Flow

sequenceDiagram
    participant User
    participant React
    participant Redis
    participant API
    participant AmaturalistAPI
    participant ContentDB

    User->>React: Request Observation Data
    React->>Redis: Check Cache (observation:{id})
    
    alt Cache Hit
        Redis-->>React: Return Cached Data
        React-->>User: Display Data
    else Cache Miss
        React->>API: GET /api/observations
        API->>AmaturalistAPI: Request with API Token
        AmaturalistAPI-->>API: Return Observation Data
        API->>Redis: Cache Data (TTL: 5min)
        API-->>React: Return Data
        React-->>User: Display Data
    end

    User->>React: Request Story Map Content
    React->>API: GET /api/storymaps/{id}
    API->>ContentDB: Query Storymap
    ContentDB-->>API: Return Storymap Content
    API-->>React: Return Content
    React-->>User: Render Story Map

3.2 Real-time Data Synchronization

graph LR
    subgraph AMATURALIST["AMATURALIST"]
        WEBHOOK[Webhook Events
New Observation]
    end

    subgraph RLU_BACKEND["RLU BACKEND"]
        WEBHOOK_HANDLER[Webhook Handler]
        REDIS_PUB[Redis Publisher]
    end

    subgraph REDIS["REDIS"]
        CHANNEL[Pub/Sub Channel
observations:updates]
    end

    subgraph RLU_FRONTEND["RLU FRONTEND"]
        SOCKET[Socket.io Client]
        REACT_STATE[React State Update]
    end

    WEBHOOK --> WEBHOOK_HANDLER
    WEBHOOK_HANDLER --> REDIS_PUB
    REDIS_PUB --> CHANNEL
    CHANNEL --> SOCKET
    SOCKET --> REACT_STATE

    style AMATURALIST fill:#ca8a04,stroke:#ea580c,stroke-width:2px,color:#ffffff
    style RLU_BACKEND fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style RLU_FRONTEND fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff

3.3 API Integration Details

3.3.1 API Endpoints Used

  • /api/general-observations

    • Purpose: Fetch Amaturalist observations (all taxa)
    • Authentication: Bearer Token (JWT)
    • Cache Strategy: Redis: 5 minutes
    • Data Scope: Location, taxonomy, and related media from observations in RLU region
    • Data Privacy: Public data only, no sensitive information, no Amaturalist user data

  • /api/taxa/{id}

    • Purpose: Fetch taxa details
    • Authentication: Bearer Token (JWT)
    • Cache Strategy: Redis: 10 minutes
    • Data Scope: Taxonomy information and related metadata
    • Data Privacy: Public data only, no sensitive information, no Amaturalist user data

3.3.2 Data Structure

Observation Data Response:

{
  "id": 12345,
  "scientific_name": "Milvus migrans",
  "common_name": "Black Kite",
  "latitude": -6.2088,
  "longitude": 106.8456,
  "observation_date": "2026-05-01T10:00:00Z",
  "images": [
    {
      "url": "https://s3.amazonaws.com/...",
      "type": "image/jpeg"
    }
  ],
  "audio": {
    "url": "https://s3.amazonaws.com/...",
    "spectrogram": "https://s3.amazonaws.com/..."
  },
  "quality": {
    "grade": "Research Grade",
    "identifications_count": 5
  },
  "location": "Jakarta, Indonesia"
}

4. Security Architecture

4.1 Security Layers

graph TB
    subgraph EXTERNAL["EXTERNAL THREATS"]
        ATTACKER[Attacker]
    end

    subgraph SECURITY_LAYERS["SECURITY LAYERS"]
        L1[Layer 1: Cloudflare WAF
DDoS Protection
Rate Limiting]
        L2[Layer 2: CDN SSL/TLS
TLS 1.3 Only
HSTS Enabled]
        L3[Layer 3: API Gateway
Request Validation
Rate Limiting per IP]
        L4[Layer 4: Authentication
JWT Token Validation
Role-based Access]
        L5[Layer 5: Application Security
Input Validation
SQL Injection Prevention]
        L6[Layer 6: Data Security
Encryption at Rest
Redis AUTH]
    end

    subgraph INTERNAL["INTERNAL ASSETS"]
        APP[RLUbiodiversity.com Application]
        DB[(Databases)]
        REDIS[(Redis)]
    end

    ATTACKER --> L1
    L1 --> L2
    L2 --> L3
    L3 --> L4
    L4 --> L5
    L5 --> L6
    L6 --> APP
    APP --> DB
    APP --> REDIS

    style SECURITY_LAYERS fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style INTERNAL fill:#059669,stroke:#16a34a,stroke-width:2px,color:#ffffff

4.2 Security Measures

4.2.1 API Authentication

  • Token Type: JWT (JSON Web Token)
  • Token Source: Provided by Amaturalist
  • Token Storage: Environment variables / AWS Secrets Manager
  • Token Refresh: Automatic refresh before expiration
  • Token Rotation: Weekly rotation for enhanced security

4.2.2 Redis Security

  • Authentication: Redis AUTH with strong password
  • Network: Private VPC network access only
  • Encryption: TLS for in-transit data
  • Access Control: IP whitelisting
  • Backup: Encrypted snapshots

4.2.3 Content Database Security

  • Encryption: AES-256 at rest
  • Backup: Daily encrypted backups
  • Access Control: Role-based permissions
  • Audit Logging: All admin actions logged

4.2.4 API Rate Limiting

  • Public Access: 1000 requests per minute per IP (frontend/home is public, no user login)
  • Admin Panel: Separate authentication for content management
  • Burst: Short burst allowance for interactive 3D rendering

4.2.5 Server/VPS Security

Operating System:

  • OS: Linux Ubuntu (Latest LTS Version)
  • Package Manager: APT for software management
  • Kernel: Hardened kernel with security patches
  • Updates: Automated security updates via unattended-upgrades

VPS Configuration (Exabytes):

  • Root Access: Disabled for security
  • SSH Access: Custom port (not default 22)
  • SSH Authentication: Key-based authentication only
  • Firewall: UFW (Uncomplicated Firewall) configured to allow only necessary ports
  • Open Ports: Only specific ports opened (HTTP, HTTPS, custom SSH port, application-specific ports)

Security Tools:

  • Fail2ban: Automated intrusion prevention system to ban malicious IPs
  • Audit Logger: Comprehensive logging of all system activities and access attempts
  • Log Rotation: Automated log rotation to prevent disk space issues

Cloudflare Configuration:

  • DNS Security: Cloudflare DNS with DNSSEC enabled
  • Cloudflare WAF: Web Application Firewall rules for common attacks
  • Cloudflare Layer 4: DDoS protection and traffic filtering
  • SSL/TLS: Cloudflare SSL/TLS termination with full encryption
  • IP Access Rules: Whitelist/blacklist for specific IP addresses
  • Bot Protection: Bot fight mode and challenge pages for suspicious traffic

4.3 VPS Security Visualization

graph LR
    ATTACKER[Attacker]
    WAF[WAF]
    DDOS[DDoS]
    DNS[DNS]
    FIREWALL[Firewall]
    SSH[SSH Port]
    HTTP[HTTP]
    HTTPS[HTTPS]
    FAIL2BAN[Fail2ban]
    SYSTEM[System]
    LOGS[Audit Logs]

    ATTACKER --> WAF
    ATTACKER --> DDOS
    ATTACKER --> DNS
    DNS --> FIREWALL
    FIREWALL --> SSH
    FIREWALL --> HTTP
    FIREWALL --> HTTPS
    SSH --> FAIL2BAN
    HTTP --> FAIL2BAN
    FAIL2BAN --> SYSTEM
    SYSTEM --> LOGS

    style ATTACKER fill:#dc2626,stroke:#b91c1c,stroke-width:2px,color:#ffffff
    style WAF fill:#059669,stroke:#16a34a,stroke-width:2px,color:#ffffff
    style DDOS fill:#059669,stroke:#16a34a,stroke-width:2px,color:#ffffff
    style DNS fill:#059669,stroke:#16a34a,stroke-width:2px,color:#ffffff
    style FIREWALL fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style FAIL2BAN fill:#ca8a04,stroke:#ea580c,stroke-width:2px,color:#ffffff
    style SYSTEM fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style LOGS fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:#ffffff

4.4 Audit Log Examples

Authentication Log Example:

2026-05-02 14:30:45 api.amaturalist.com sshd[1234]: Accepted publickey for admin from 192.168.1.100 port 54321 ssh2
2026-05-02 14:31:22 api.amaturalist.com sshd[1235]: Invalid user test from 203.0.113.50 port 22
2026-05-02 14:31:23 api.amaturalist.com sshd[1235]: Failed password for invalid user test from 203.0.113.50 port 22 ssh2
2026-05-02 14:31:24 api.amaturalist.com fail2ban.actions[5678]: NOTICE [sshd] Ban 203.0.113.50

System Log Example:

2026-05-02 14:30:00 api.amaturalist.com kernel: [UFW BLOCK] IN=eth0 SRC=203.0.113.50 DST=10.0.0.5 PROTO=TCP DPT=22
2026-05-02 14:30:01 api.amaturalist.com systemd[1]: Started Session 1234 of user admin
2026-05-02 14:30:02 api.amaturalist.com systemd[1]: Starting Daily apt download activities...
2026-05-02 14:30:10 api.amaturalist.com apt[9012]: Unattended upgrade: linux-image-generic installed

Application Log Example:

[2026-05-02 14:30:15] production.INFO: User admin logged in via access token
[2026-05-02 14:30:20] production.INFO: API request /api/general-observations from 192.168.1.100
[2026-05-02 14:30:25] production.WARNING: Rate limit exceeded for IP 203.0.113.50
[2026-05-02 14:30:30] production.ERROR: Database connection failed - retrying

4.5 Attacker Outcome

Attack Prevention Flow:

  1. Cloudflare Layer: Attacker blocked by WAF rules, DDoS protection, and IP access rules
  2. Firewall Layer: UFW blocks unauthorized ports and restricts access to only allowed services
  3. Fail2ban Layer: Automated IP banning after repeated failed attempts (SSH brute force, malicious requests)
  4. Application Layer: Rate limiting and authentication prevent unauthorized access

Final Outcome:

  • Legitimate Traffic: Passes through all security layers and reaches the application
  • Malicious Traffic: Blocked at one or more security layers (Cloudflare, Firewall, or Fail2ban)
  • Compromised IPs: Banned permanently or temporarily depending on threat level
  • Audit Trail: All activities logged for forensic analysis and compliance

4.6 Attack Notification and Incident Response

Failed Attack Notifications:

When an attack is blocked at any security layer, the following notifications are sent to responsible personnel:

  • Uptime Robot Webhook: Instant notification when downtime or unusual traffic patterns detected
  • Email Alerts: Sent to security team and system administrators
  • Application Alerts: In-app notifications for critical security events
  • Log Alerts: Automated monitoring for repeated failed login attempts, brute force attacks

Notification Channels:

  • Primary: Uptime Robot webhook
  • Secondary: Email
  • Tertiary: SMS (if configured for critical alerts)
  • Quaternary: In-app dashboard notifications

Successful Breach Response (ASAP):

If an attacker successfully bypasses all security layers and gains unauthorized access:

  1. Immediate Actions (within 5 minutes):

    • Trigger emergency alert to all security team members
    • Isolate affected systems from network
    • Change all compromised credentials immediately
    • Enable maintenance mode to prevent further damage

  2. Containment (within 15 minutes):

    • Shut down affected services temporarily
    • Preserve forensic evidence (logs, memory dumps)
    • Block attacker IP addresses at Cloudflare level
    • Rotate all access tokens and API keys

  3. Investigation (within 1 hour):

    • Analyze attack vectors and entry points
    • Identify compromised data and systems
    • Determine scope of breach
    • Begin forensic analysis

  4. Recovery (within 24 hours):

    • Patch security vulnerabilities
    • Restore systems from clean backups
    • Implement additional security controls
    • Conduct post-incident review

  5. Communication:

    • Notify stakeholders and affected users
    • Document incident timeline and actions taken
    • Update security policies based on lessons learned
    • Report to relevant authorities if required by law

5. Caching Strategy

5.1 Redis Cache Configuration

graph TB
    subgraph CACHE_TYPES["CACHE TYPES"]
        OBS_CACHE["Observations Cache
Key: obs:id
TTL: 5 minutes"]
        TAXA_CACHE["Taxa Cache
Key: taxa:id
TTL: 10 minutes"]
        TILE_CACHE["Map Tiles Cache
Key: tile:z:x:y
TTL: 1 hour"]
        STORY_CACHE["Story Maps Cache
Key: story:id
TTL: 15 minutes"]
        SESSION_CACHE["Session Cache
Key: session:token
TTL: 24 hours"]
    end

    subgraph INVALIDATION["CACHE INVALIDATION"]
        OBS_INVALID["Observation Updates
Invalidate obs:id"]
        TAXA_INVALID["Taxa Updates
Invalidate taxa:id"]
        MANUAL_INVALID["Manual Flush
Admin Triggered"]
    end

    OBS_CACHE --> OBS_INVALID
    TAXA_CACHE --> TAXA_INVALID
    STORY_CACHE --> MANUAL_INVALID
    TILE_CACHE --> MANUAL_INVALID
    SESSION_CACHE --> MANUAL_INVALID

    style CACHE_TYPES fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style INVALIDATION fill:#ca8a04,stroke:#ea580c,stroke-width:2px,color:#ffffff

5.2 Cache Keys Pattern

  • obs:{id}

    • Description: Single observation data
    • TTL: 5 minutes

  • obs:list:{page}:{filters_hash}

    • Description: Observation list with filters
    • TTL: 5 minutes

  • taxa:{id}

    • Description: Taxa details
    • TTL: 10 minutes

  • taxa:search:{query}

    • Description: Taxa search results
    • TTL: 10 minutes

  • tile:{z}:{x}:{y}

    • Description: Map tile data
    • TTL: 1 hour

  • story:{id}

    • Description: Story map content
    • TTL: 15 minutes

  • story:list

    • Description: Story maps list
    • TTL: 15 minutes

  • session:{token}

    • Description: Admin session data (admin panel only)
    • TTL: 24 hours

5.3 Cache Invalidation Strategy

  1. Time-based Invalidation: TTL expiration
  2. Event-based Invalidation: Webhook triggers from Amaturalist
  3. Manual Invalidation: Admin panel cache flush
  4. Selective Invalidation: Invalidate only affected keys

6. Admin Panel Architecture

6.1 Admin Panel Components

graph TB
    subgraph ADMIN_PANEL["ADMIN PANEL"]
        DASHBOARD[Dashboard
Statistics Overview]
        CONTENT_MGMT[Content Management
Story Maps
Media Upload]
        USER_MGMT[User Management
Admin List
Permissions]
        CACHE_MGMT[Cache Management
Manual Flush
Monitoring]
        SETTINGS[Settings
API Configuration
System Config]
    end

    subgraph ADMIN_FEATURES["ADMIN FEATURES"]
        STORY_EDITOR[Story Map Editor
Rich Text Editor
Media Embed]
        MEDIA_UPLOAD[Media Upload
Image/Audio Upload
S3 Integration]
        ADMIN_LOGS[Admin Activity Logs
Audit Trail]
        MONITORING[System Monitoring
Performance Metrics]
    end

    ADMIN_PANEL --> ADMIN_FEATURES

    style ADMIN_PANEL fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style ADMIN_FEATURES fill:#059669,stroke:#16a34a,stroke-width:2px,color:#ffffff

6.2 Admin Roles and Permissions

  • Super Admin

    • Permissions: Full system access, user management, configuration, token generation
    • Access Level: Level 5

  • Content Admin

    • Permissions: Story maps, media upload, content management
    • Access Level: Level 4

6.3 Admin Panel Access Control

Admin panel uses token-based authentication:

  • Access Token Generation: Super Admin RLU creates unique access tokens
  • Default Access Token: Default token provided to Super Admin on first setup, must be changed immediately
  • Login Page Access: Login page only accessible with valid access token
  • Token Distribution: Tokens distributed securely to authorized admins
  • Token Validation: Token verified before allowing login page access

7. Three.js Visualization Architecture

7.1 3D Rendering Pipeline

graph LR
    subgraph DATA_SOURCE["DATA SOURCE"]
        API_DATA[API Response
Observations]
        GEO_DATA[Geospatial Data
Coordinates]
        MEDIA_DATA[Media Files
Images/Audio]
    end

    subgraph PREPROCESSING["PREPROCESSING"]
        DATA_TRANSFORM[Data Transformation
Coordinate Conversion]
        LOD_GENERATION[LOD Generation
Level of Detail]
        TEXTURE_COMP[Texture Compression
Optimization]
    end

    subgraph THREE_JS["THREE.JS RENDERING"]
        SCENE[Scene Setup
Camera/Lights]
        GEOMETRY[Geometry Creation
Points/Meshes]
        MATERIALS[Materials
Textures/Shaders]
        ANIMATION[Animation
Transitions]
    end

    subgraph RENDER["RENDER"]
        WEBGL_RENDERER[WebGL Renderer
Post-processing]
        CANVAS[Canvas Output
Display]
    end

    DATA_SOURCE --> PREPROCESSING
    PREPROCESSING --> THREE_JS
    THREE_JS --> RENDER

    style DATA_SOURCE fill:#ca8a04,stroke:#ea580c,stroke-width:2px,color:#ffffff
    style PREPROCESSING fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style THREE_JS fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style RENDER fill:#059669,stroke:#16a34a,stroke-width:2px,color:#ffffff

7.2 Visualization Features

  • 3D Point Cloud: Observation points in 3D space
  • Terrain Rendering: Elevation data visualization
  • Heat Maps: Density visualization
  • Timeline Animation: Time-based observation playback
  • Interactive Controls: Zoom, rotate, pan
  • Performance Optimization: LOD, frustum culling, instancing

8. Deployment Architecture

8.1 Infrastructure

graph TB
    subgraph PRODUCTION["PRODUCTION ENVIRONMENT"]
        subgraph FRONTEND["FRONTEND"]
            EXABYTES_WEB[Exabytes Web Hosting
Static Files
React Build]
        end

        subgraph BACKEND["BACKEND"]
            LARAVEL[Laravel Application
API Endpoints
Business Logic]
            MYSQL[(MySQL/PostgreSQL
Database)]
            REDIS[(Redis
Cache)]
        end

        subgraph STORAGE["STORAGE"]
            LOCAL[(Local Storage
Media Files)]
            CLOUDFRONT[Cloudflare
CDN]
        end
    end

    subgraph MONITORING["MONITORING & LOGGING"]
        UPTIME[Uptime Robot
Uptime Monitoring
Alerts]
        LOGS[Application Logs
Laravel Log Viewer]
        METRICS[Performance Metrics
Custom Dashboard]
    end

    FRONTEND --> BACKEND
    BACKEND --> MYSQL
    BACKEND --> REDIS
    BACKEND --> LOCAL
    LOCAL --> CLOUDFRONT
    FRONTEND --> CLOUDFRONT
    BACKEND --> MONITORING
    FRONTEND --> MONITORING

    style PRODUCTION fill:#0066cc,stroke:#0088ff,stroke-width:2px,color:#ffffff
    style MONITORING fill:#ca8a04,stroke:#ea580c,stroke-width:2px,color:#ffffff

8.2 Environment Configuration

  • Development

    • Purpose: Local development
    • Database: Local MySQL/SQLite
    • Cache: Local Redis

  • Staging

    • Purpose: Pre-production testing
    • Database: Exabytes Dev DB
    • Cache: Redis Dev

  • Production

    • Purpose: Live production
    • Database: Exabytes Prod DB
    • Cache: Redis Prod

9. Disaster Recovery

9.1 Backup Strategy

  • Database: Daily automated backups via Exabytes control panel, 30-day retention
  • Redis: Daily RDB snapshots, 7-day retention
  • Media Files: Local storage backups, 30-day retention
  • Code: Git repository with version control

9.2 Recovery Procedures

  1. Database Recovery: Restore from Exabytes backup snapshots
  2. Cache Recovery: Rebuild from database if Redis fails
  3. Application Recovery: Automated rollback to previous stable version via Git
  4. Data Sync: Re-sync with Amaturalist API after recovery

10. Performance Optimization

10.1 Frontend Optimization

  • Code Splitting: Lazy loading of components
  • Image Optimization: WebP format, lazy loading
  • 3D Optimization: LOD, instancing, geometry compression
  • Bundle Size: Tree shaking, minification
  • CDN: Static assets served via CDN

10.2 Backend Optimization

  • API Caching: Redis caching for all external API calls
  • Database Indexing: Optimized queries with proper indexes
  • Connection Pooling: Database connection reuse
  • Compression: Gzip/Brotli compression
  • Rate Limiting: Prevent abuse and ensure fair usage

11. Monitoring and Logging

11.1 Metrics Tracked

  • Application Metrics: Response time, error rate, throughput
  • Business Metrics: Active users, data consumption, cache hit rate
  • Infrastructure Metrics: CPU, memory, disk usage
  • API Metrics: External API latency, token usage

11.2 Monitoring Tools

  • Uptime Robot: Continuous uptime monitoring for all endpoints
    • Monitor API endpoints every 5 minutes
    • Monitor frontend website every 5 minutes
    • Alert via webhook from Uptime Robot application when downtime detected + email
    • Response time monitoring
  • Laravel Log Viewer: Built-in log viewer for application logs
  • Custom Dashboard: Basic performance metrics dashboard

11.3 Alerting

  • Critical: Application down, database connection failure
  • Warning: High error rate, slow response times
  • Info: Cache miss rate increase, unusual traffic patterns

12. Compliance and Certifications

12.1 TISAX Compliance

This architecture is designed to support TISAX (Trusted Information Security Assessment Exchange) requirements:

  • Information Security: Implemented multi-layer security architecture
  • Data Protection: Encryption at rest and in transit
  • Access Control: Role-based access control and audit logging
  • Availability: High availability with CDN and redundancy
  • Confidentiality: Data isolation and secure API integration

12.2 Additional Compliance

  • GDPR: Data privacy and user consent management
  • ISO 27001: Information security management system (planned)
  • SOC 2: Security and availability controls (planned)