System Architecture
This document describes the full-stack infrastructure of the GSCX platform, including client endpoints, load balancing, redundant web and database tiers, and the integrated Beezifi cybersecurity stack — from on-host intrusion detection through to the Beezifi Cybersecurity Command Center (BC3).
Architecture Pattern
3-Tier + Security Overlay
Redundancy Model
Active / Active with Hot Standby
Web Server Nodes
2× (Primary + Standby)
Database Nodes
2× (Primary + Replica)
IDS Coverage
All server nodes
Security Operations
BC3 (Analysts + AI Agents)
Design Philosophy: Every infrastructure layer is deployed with a redundant peer. No single server constitutes a single point of failure. Security telemetry is collected at every node and centralized in BC3 for both automated and human-directed response.
Architecture Diagram
The diagram below illustrates all tiers from client devices through to the database layer and the parallel security telemetry pipeline feeding BC3.
Client Tier
Laptops &
Desktops
Desktops
HTTPS / TLS 1.3
Workstations
HTTPS / TLS 1.3
Mobile Phones
HTTPS / TLS 1.3
Internet · TLS 1.3 · Port 443
Load Balancer Tier
Load Balancer
Primary · Round-Robin
Health Checks · SSL Termination
Health Checks · SSL Termination
+ Hot Standby LB
Load Balancer
Standby · Auto-Failover
VRRP / Floating IP
VRRP / Floating IP
Internal Network · HTTP/2 · mTLS
Web Server Tier
Web Server A
8 Cores · 32 GB RAM
128 GB SSD · Node.js/Express
Beezifi IDS ✦
128 GB SSD · Node.js/Express
Beezifi IDS ✦
Web Server B
8 Cores · 32 GB RAM
128 GB SSD · Node.js/Express
Beezifi IDS ✦
128 GB SSD · Node.js/Express
Beezifi IDS ✦
Private DB Network · Encrypted · Port 3306
Database Tier
Database Server — Primary
32 Cores · 128 GB RAM
24 TB SSD · MariaDB/MySQL
Beezifi IDS ✦
24 TB SSD · MariaDB/MySQL
Beezifi IDS ✦
Database Server — Replica
32 Cores · 128 GB RAM
24 TB SSD · MariaDB/MySQL
Beezifi IDS ✦ · Sync Replication
24 TB SSD · MariaDB/MySQL
Beezifi IDS ✦ · Sync Replication
Security Telemetry Pipeline
Beezifi IDS Endpoint
On every server node
Inbound + outbound IP capture
Auto-block malicious IPs
Inbound + outbound IP capture
Auto-block malicious IPs
→
BC3 — Beezifi Cybersecurity
Command Center
Command Center
Centralized threat intelligence
Security Analysts + AI Agents
Proactive IP blocking & response
Security Analysts + AI Agents
Proactive IP blocking & response
→
AI Security Agents
Automated threat hunting
Pattern analysis
Autonomous response
Pattern analysis
Autonomous response
✦ Beezifi IDS is deployed on every web server and database server node. Telemetry from all nodes streams in real-time to the BC3 Command Center, providing full east-west and north-south visibility.
Traffic Flow
The following steps describe the complete path of a client request from origin to data and back.
1
Client Request Initiated
A laptop, desktop workstation, or mobile phone sends an HTTPS request over TLS 1.3 to the platform's public IP / domain. All client traffic is encrypted in transit — no plain HTTP accepted.
2
Load Balancer — SSL Termination & Routing
The primary Load Balancer terminates TLS, performs IP reputation pre-screening, and forwards the request via round-robin (or least-connections) to an available Web Server node. The hot-standby LB monitors via VRRP and claims the floating IP within seconds should the primary fail.
3
Beezifi IDS — Inbound Scan (Web Tier)
As the request enters the web server, the Beezifi Intrusion Detection software inspects the source IP and payload signature. Flagged IPs are automatically blocked at the host firewall. The source IP is also forwarded to the BC3 telemetry pipeline.
4
Application Processing (Node.js / Express)
The GSCX Express application handles authentication, business logic, and constructs a database query. Session tokens are validated; compliance middleware runs before any data operation.
5
Database Query — Primary Node
Queries are directed to the Primary Database Server over the encrypted private DB network. The Beezifi IDS on the DB host monitors all connection attempts and queries for anomalous patterns.
6
Synchronous Replication to Replica
Every write committed to the Primary DB is synchronously replicated to the Replica DB Server before the transaction is acknowledged. This ensures zero data loss on primary failure.
7
Beezifi IDS — Outbound Scan & Telemetry Dispatch
On the response path, the IDS endpoint records the destination IP (client). All captured IP metadata — inbound source and outbound destination — is streamed to the BC3 Command Center for analysis.
8
BC3 Threat Analysis & Response
BC3 receives telemetry from all nodes. AI Security Agents correlate patterns across the fleet in real time. Human security analysts review escalated events. Identified bad actors are proactively blocked across all nodes simultaneously via push-down firewall rules.
9
Response Returned to Client
The web server returns the JSON API response to the load balancer, which re-encrypts with TLS and delivers to the client browser or mobile app.
Client Tier
The GSCX platform is device-agnostic. All three client categories connect using standard HTTPS (port 443) with TLS 1.3 enforced at the load balancer.
💻 Laptops / Notebooks
Browser-based SPA
🖥️ Desktop Workstations
Browser-based SPA
📱 Mobile Phones
Responsive SPA / PWA
Client Security Requirements
- TLS 1.3 minimum — older protocol versions are rejected at the load balancer
- All session tokens stored in
sessionStorage(not persisted to disk) - TOTP second factor required for privileged role actions
- No sensitive data cached in browser localStorage
Load Balancer Tier
A redundant load balancer pair sits at the internet edge. The primary node handles all active traffic; the standby node monitors via VRRP heartbeat and assumes the floating public IP within seconds of a detected failure.
Topology
Active / Hot-Standby
Protocol
VRRP Failover
Failover Time
< 5 seconds
TLS Termination
TLS 1.3 at edge
Routing Algorithm
Round-Robin + Health Check
Health Check Interval
5 seconds
Load Balancer Responsibilities
- Terminate inbound TLS; forward to web servers over internal mTLS
- Distribute traffic evenly across Web Server A and Web Server B
- Remove unhealthy web server nodes from the rotation automatically
- Rate-limit excessive connection attempts per source IP
- Forward real client IP via
X-Forwarded-Forheader for IDS logging
Redundancy Note: If the primary load balancer fails, the standby node claims the shared virtual IP via VRRP within 2–5 seconds. No manual intervention is required. Clients experience at most one interrupted request during failover.
Web Server Tier
Two identical web server nodes run in an active-active configuration behind the load balancer. Both nodes serve live traffic simultaneously, maximizing throughput and providing immediate redundancy.
Hardware Specification
Node Count
2 (Active-Active)
Runtime
Node.js (CommonJS)
Framework
Express 4.x
Process Manager
PM2 Cluster Mode
Session Storage
Shared (DB-backed)
IDS
Beezifi IDS (on-host)
Web Server Software Stack
| Component | Software | Role |
|---|---|---|
| Application Runtime | Node.js | Execute GSCX Express application |
| Web Framework | Express 4.x | REST API routing, middleware pipeline |
| Process Manager | PM2 | Cluster mode (8 workers), auto-restart, zero-downtime reload |
| Reverse Proxy | Nginx | Internal TLS termination, static asset cache |
| Intrusion Detection | Beezifi IDS | Real-time IP inspection, automatic blocking, telemetry |
| Host Firewall | iptables / nftables | Enforce blocklist pushed from BC3 |
| Log Shipping | Filebeat | Forward access and error logs to BC3 SIEM |
Active-Active Redundancy
Both web server nodes run identical application versions at all times. The load balancer performs health checks every 5 seconds against each node's /api/health endpoint. If a node fails its health check three consecutive times, it is removed from rotation and the surviving node absorbs all traffic until the failed node recovers.
Zero-Downtime Deployments: PM2 cluster mode enables rolling restarts. The load balancer health check ensures no in-flight requests are terminated during a software update.
Database Server Tier
Two database servers — Primary and Replica — operate in a synchronous replication configuration. Writes go to the Primary; the Replica is promoted automatically on Primary failure. Both nodes run Beezifi IDS for east-west traffic monitoring.
Hardware Specification
Node Count
2 (Primary + Replica)
Database Engine
MariaDB / MySQL
Replication
Synchronous (Semi-Sync)
RPO (Data Loss)
~0 (semi-sync)
RTO (Downtime)
< 30 seconds
IDS
Beezifi IDS (on-host)
Database Software Stack
| Component | Software | Role |
|---|---|---|
| Database Engine | MariaDB 10.x | Relational data store for all GSCX platform data |
| Replication | Semi-Sync Replication | Writes acknowledged only after replica confirms receipt |
| HA Orchestration | Orchestrator / MHA | Monitors topology, triggers automatic failover |
| Backup | Percona XtraBackup | Hot physical backups — no downtime required |
| Intrusion Detection | Beezifi IDS | Monitor DB connection attempts, query anomalies, lateral movement |
| Audit Log | MariaDB Audit Plugin | Capture all DDL/DML for compliance and forensics |
Database Isolation: The database servers are not directly reachable from the internet or the load balancer. Only the web server nodes may connect to the DB tier, enforced by host-based firewall rules and a dedicated private VLAN.
Beezifi Intrusion Detection System
Beezifi IDS is deployed as an on-host agent on every web server and database server node. It provides real-time inspection of all network traffic entering and leaving each host and enforces automatic blocking of identified malicious actors.
Core Capabilities
Deep Packet Inspection
Beezifi IDS inspects all inbound and outbound traffic at the network layer. Signatures for known attack patterns — SQL injection probes, XSS payloads, port scans, brute-force login attempts, and exploit kits — are matched in real time against live traffic streams.
Automatic Malicious IP Blocking
When a source IP is identified as malicious — either by signature match, behavioral anomaly, or threat feed lookup — Beezifi IDS immediately injects a
DROP rule into the host firewall (iptables / nftables). No manual intervention required. Blocks take effect in under 100ms.IP Telemetry Collection
Every inbound source IP and outbound destination IP processed by the host is captured by the Beezifi IDS Endpoint and forwarded to the BC3 Command Center over an encrypted telemetry channel. This provides full network visibility for threat hunting and forensic investigation.
Threat Feed Integration
Beezifi IDS continuously syncs with curated threat intelligence feeds (known bad IPs, Tor exit nodes, botnet C2 infrastructure, compromised hosting ranges). Pre-emptive blocks are applied before a connection is even attempted.
Beezifi IDS Endpoint
The Beezifi Intrusion Detection Endpoint is the per-host telemetry agent that bridges on-host detection activity to the centralized BC3 Command Center.
Endpoint Data Pipeline
| Data Collected | Direction | Destination | Frequency |
|---|---|---|---|
| Source IP of every inbound connection | Inbound | BC3 Threat Intelligence | Real-time stream |
| Destination IP of every outbound connection | Outbound | BC3 Threat Intelligence | Real-time stream |
| Block events (auto-blocked IPs) | Event | BC3 Incident Queue | Immediate push |
| Anomaly alerts (behavioral deviation) | Alert | BC3 Analyst Dashboard | Immediate push |
| Host health metrics (CPU, mem, net) | Health | BC3 Monitoring | Every 30 seconds |
Endpoint Deployment: One Beezifi IDS Endpoint agent runs on each of the two web servers and each of the two database servers — four agents total. All four stream to a single BC3 instance, giving security teams a unified cross-node view.
Beezifi Cybersecurity Command Center (BC3)
BC3 is the centralized security operations platform that aggregates telemetry from all Beezifi IDS Endpoint agents across the infrastructure. It provides the tooling, dashboards, and orchestration layer for both human security analysts and AI Security Agents.
BC3 Architecture
Input Sources
All IDS Endpoints (×4 nodes)
Telemetry Ingestion
Real-time streaming
Analyst Interface
SOC Dashboard + Incident Queue
AI Agents
Automated threat response
Blocklist Push
All nodes simultaneously
Retention
90-day hot / 1-year cold
BC3 Functional Modules
Threat Intelligence Aggregator
Ingests raw IP telemetry from all four Beezifi IDS Endpoint agents. Correlates events across nodes to detect distributed attack campaigns that would be invisible from any single host perspective (e.g., low-rate scans spread across multiple source IPs).
SOC Analyst Dashboard
Provides security analysts with live network maps, alert timelines, IP geolocation overlays, and drill-down incident views. Analysts can manually escalate, suppress, or override automated decisions. All analyst actions are audit-logged.
Blocklist Orchestrator
Maintains a master IP blocklist shared across all server nodes. When BC3 (human or AI) decides to block an IP, the Blocklist Orchestrator pushes the rule to every IDS Endpoint agent simultaneously, ensuring fleet-wide blocking within seconds.
SIEM & Log Archive
All inbound/outbound IP records, block events, and anomaly alerts are indexed and searchable for forensic investigation and compliance reporting. Data is retained for 90 days in hot storage (fast query) and 1 year in cold archival storage.
AI Security Agents
BC3 integrates AI Security Agents that operate autonomously alongside human analysts. These agents continuously analyze telemetry streams, learn from historical patterns, and execute response actions without waiting for human approval — compressing threat response time from minutes to milliseconds.
Proactive Posture: The AI agents are not reactive-only. They build behavioral baselines for every known IP and flag deviations before an attack completes, enabling pre-emptive blocking of bad actors before damage occurs.
AI Agent Capabilities
Behavioral Anomaly Detection
AI agents build statistical models of normal traffic patterns per endpoint, per hour of day, and per user cohort. Deviations — sudden connection spikes, unusual port access, geographic impossibility — trigger automated investigation workflows.
Cross-Node Correlation
A single attacker probing multiple nodes from rotating IPs would evade per-host detection. AI agents correlate timing, payload similarity, and TTL fingerprints across all four server nodes to identify and block coordinated attack campaigns.
Autonomous Response Execution
For high-confidence threat classifications, AI agents push block rules directly through the BC3 Blocklist Orchestrator to all nodes. Lower-confidence findings are escalated to the human analyst queue for review rather than acting autonomously.
Continuous Learning
Analyst decisions (confirm block, false-positive override, escalate) feed back into the AI models as labeled ground-truth data. The agents improve their classification accuracy over time, reducing false positives and closing detection gaps.
Human-AI Collaboration Model
| Threat Confidence | AI Action | Analyst Role |
|---|---|---|
| High (>95%) | Autonomous block pushed to all nodes | Notified; can override within 15 min |
| Medium (60–95%) | Temporary block + escalate to queue | Reviews and confirms or reverses |
| Low (<60%) | Flag and watch; no block | Reviews enriched alert; decides action |
| Unknown / Novel | Capture and sandbox; immediate escalate | Hands-on forensic investigation |
Redundancy Strategy
Every tier of the infrastructure is designed with a redundant peer. The following table summarizes redundancy across the full stack.
| Tier | Primary | Redundant Peer | Failover Mode | RTO |
|---|---|---|---|---|
| Load Balancer | LB Primary | LB Hot Standby | VRRP / Floating IP | < 5 sec |
| Web Server | Web Server A | Web Server B | Active-Active; LB removes failed node | Instant (no failover needed) |
| Database | DB Primary | DB Replica | Semi-sync replication; auto-promote | < 30 sec |
| BC3 / IDS | BC3 Primary | BC3 Warm Standby | State sync; manual or auto-promote | < 60 sec |
No Single Points of Failure
- Client connectivity: Multiple ISP uplinks on the load balancer pair
- Load balancer: Hot-standby with shared virtual IP via VRRP
- Web application: Two active nodes; either can serve all traffic alone
- Database writes: Semi-synchronous replication — replica is always current
- Database reads: Can be offloaded to replica during primary maintenance
- Security monitoring: BC3 warm standby preserves telemetry continuity
Failover & Recovery Procedures
Load Balancer Failover
- VRRP keepalive packet is missed by the standby LB (threshold: 3 missed at 1-second interval)
- Standby LB claims the floating public IP via gratuitous ARP broadcast
- DNS / BGP upstream sees no change — the IP is the same
- Traffic resumes through the standby within 2–5 seconds
- On-call alert fires to the operations team for investigation
Web Server Node Failure
- Load balancer health check fails three consecutive times against the affected node
- Node is removed from the active rotation — zero new requests are sent to it
- Surviving node absorbs 100% of traffic (8 PM2 workers provide ample headroom)
- PM2 on the failed node attempts automatic process restart
- Once health check passes, the node is reintroduced to the rotation gracefully
Database Primary Failure
- Orchestrator detects Primary DB is unreachable (3 consecutive missed heartbeats)
- Replica is confirmed up-to-date (semi-sync guarantees no data loss)
- Replica is promoted to Primary — VIP / DNS CNAME updated automatically
- Web servers reconnect to new Primary using connection pool retry logic
- A new Replica is provisioned from the promoted Primary to restore HA state
Backup Schedule: Full physical backups via Percona XtraBackup run nightly at 02:00 UTC. Incremental backups run every 4 hours. Backups are stored off-site in a geographically separate location and retained for 30 days.
Hardware Summary
| Node | Count | CPU Cores | RAM | Storage | Role |
|---|---|---|---|---|---|
| Load Balancer | 2 | — | — | — | Traffic routing, TLS termination, HA pair |
| Web Server | 2 | 8 | 32 GB | 128 GB SSD | Node.js/Express API, SPA serving |
| Database Server | 2 | 32 | 128 GB | 24 TB SSD | MariaDB Primary + Replica |
Software Summary
| Software | Deployed On | Purpose | Status |
|---|---|---|---|
| Node.js / Express | Web Server A, B | GSCX REST API and SPA backend | Active |
| PM2 | Web Server A, B | Cluster process manager, zero-downtime deploys | Active |
| Nginx | Web Server A, B | Reverse proxy, static asset serving, mTLS | Active |
| MariaDB | DB Primary, Replica | Relational data store | Active |
| Beezifi IDS | Web Server A, B · DB Primary, Replica | On-host intrusion detection, auto IP blocking | Security |
| Beezifi IDS Endpoint | Web Server A, B · DB Primary, Replica | IP telemetry collection, streaming to BC3 | Security |
| BC3 (Beezifi Cybersecurity Command Center) | Dedicated BC3 Server (HA pair) | Centralized threat intelligence, analyst dashboard, AI agents | Command |
| AI Security Agents | BC3 | Automated threat detection, behavioral analysis, autonomous response | Command |
| Percona XtraBackup | DB Primary, Replica | Hot physical database backups | Ops |
| Filebeat | All server nodes | Log shipping to BC3 SIEM | Ops |
Security Coverage: Beezifi IDS and Beezifi IDS Endpoint are deployed on 100% of server nodes. No node in the infrastructure is unmonitored. BC3 provides a single pane of glass across all four server nodes, load balancers, and all telemetry feeds.