Database Structure

At the foundation, the model emphasizes Tenant Isolation. Each ISP operates on a dedicated database environment, eliminating the risks of shared-schema architectures. This means no cross-tenant data exposure, no noisy neighbors, and no performance contention.

It’s a deliberate architectural decision: instead of optimizing for simplicity, WISPGate optimizes for security, scalability, and operational independence per customer.

At the center sits the Core Database Cluster, designed for reliability and continuity. High availability, replication, and failover are not optional features here—they are baseline requirements.

The inclusion of read/write separation highlights that the system is built to handle both transactional workloads (billing, provisioning) and read-heavy operations (dashboards, reporting) without degrading performance.

On the performance side, the Cache Layer (e.g., Redis) is positioned to handle real-time demands—session lookups, rate limiting, and high-frequency queries.

This reduces pressure on the core database and ensures low-latency responses where it matters most, especially for AAA and live network interactions.

Finally, the Analytics & Logs layer separates operational data from analytical workloads.

Usage records, logs, and metrics are processed and stored independently, enabling reporting and insights without impacting transactional performance. This separation is what allows the system to scale without becoming slow or unstable over time.