Roari SolutionsFrom a Constrained VPS to a Standalone, Integrated LMS
Background
The university's platform began as a set of applications covering admissions, academics, results, finance, the public website and management. All of them shared one PostgreSQL database and ran on a single VPS. That setup suited administrative work, which is mostly low-volume reads and writes spread evenly across the day. Adding e-learning raised the question of whether the same server could carry it.
The Problem
A learning management system loads a server very differently. Students upload assignments, lecturers publish videos and course files, and quizzes draw hundreds of simultaneous sessions within a few minutes. On one VPS, those spikes would compete for the CPU, memory and disk I/O that results publication and registration depend on. Course media would also fill the storage that holds official records and backups. One heavy exam week could slow or stop the systems the university cannot afford to lose. Scaling the VPS vertically would mean paying all year for capacity needed only a few weeks per semester.
The Idea
Instead of building the LMS into the core platform, we designed it as a separate system that stays integrated. It runs on its own infrastructure and can scale, restart or fail without affecting the core. Integration comes from PostgreSQL logical replication: the core database runs with wal_level=logical, and the LMS subscribes to the data it needs, such as students, courses, enrolments and staff. Roles reserved for the LMS (teacher, lms-admin) already exist in the core's permission model, so identity and access stay consistent across both systems.
Outcome
This design gave us three advantages:
• Isolation: the extra load from e-learning never reaches the registrar's systems.
• One source of truth: the LMS reads academic data and never duplicates or edits it.
• Modularity: the LMS is deployed per institution, only when needed. The core platform therefore stays light enough for a modest VPS, and the LMS becomes an optional add-on rather than a requirement.
The server's limits forced a decision, and that decision became a better product architecture.