Project Onyx: A No-Fail LMS for a leading Management Consultancy

The Mission

Our client, a high-end management consultancy in India, was hit by a classic "scale" problem. They were growing fast: from 50-odd associates to 500 during the course of a year. Each new associate had to go through a set of mandatory training modules before they could be assigned to client projects. And herein lay the problem.

For a 50-people firm hiring 5-10 new associates a year, training can happen offline. A few senior associates can deliver those modules by setting aside five hours a week.

For a firm trying to onboard 500 new hires, the offline solution becomes insurmountable. Our client tried a number of solutions before engaging us, ranging from having senior associates record training modules and uploading them on Google Drive, to purchasing SaaS solutions that promised the world but delivered little.

In the end, they were fumbling through a patchwork of third-party tools and scattered videos that felt clunky, and frankly, looked unprofessional to their high-performing staff.

They needed a central source of truth for training that could bring all their training modules (internally produced, and licensed from third parties) into a single system.

What the system had to do

Most "off-the-shelf" LMS platforms are too rigid or too bloated. We built a lean, production-grade system tailored to their specific workflow:

• The "Traveler" Mode: Consultants are often on planes. The mobile app needed a robust offline-first architecture to allow learning without an internet connection.
• Granular Hierarchy: Managers needed to see exactly where their teams were stalling, requiring a complex reporting engine that mirrored the company’s internal org chart.
• Content Hybridity: The system had to ingest messy, older licensed content standards and display them alongside modern, 4K internal video streams without a hitch.
• Certification Guardrails: For certain compliance modules, the system needed "uncheatable" assessment logic—randomized question banks and strict anti-skipping measures on videos.

The Architecture

Given these specific requirements, the team at E-Tree Tech came up with a lean, microservices-based architecture. We broke the backend into seven core Java microservices, each handling a specific responsibility.

We chose a microservices-based architecture so that the system didn't melt under specific pressures of an enterprise environment. While a monolith would have been faster to ship initially, it would have created a single point of failure, which wouldn't fly with our client.

Specifically, different modules in the architecture had different resource needs. The Media Service, handling 4K video streams, is incredibly CPU and bandwidth intensive. On the other hand, services like Auth Service and Progress Tracker are more lightweight. With a microservices-based architecture, we could deploy the Media Service on beefier servers on AWS, while ensuring cost alignment by selecting smaller instances for other services.

Technical Hurdles (and how we cleared them)

1. The "Race Condition" in Learning Progress

The Problem: When users switched between the web app and mobile app quickly, or lost connection mid-lesson, the "percent complete" would often overwrite itself with older data.

The Solution: We moved away from simple "last-update-wins" logic. We implemented a Vector Clock versioning system for progress pings. The backend now evaluates the sequence of events, ensuring that a "lesson complete" event from a mobile device (even if synced late) takes precedence over an earlier "in-progress" heartbeat from the web.

2. The 4K Video Bottleneck

The Problem: Internal training videos were massive. Serving them raw from a server would have killed the budget and the user experience in low-bandwidth regions.

The Solution: We built a serverless transcoding pipeline. When a partner uploads a video, AWS Lambda triggers a series of jobs to slice the video into HLS (HTTP Live Streaming) chunks at five different bitrates. The Flutter player then dynamically switches quality based on the user's real-time speed.

3. Integrating Legacy SCORM Content

The Problem: Licensed third-party courses use an old standard called SCORM. It’s essentially a 20-year-old "black box" that doesn't play nice with modern Flutter apps.

The Solution: We built a custom "wrapper" service. We hosted the legacy content in a sandboxed WebView and engineered a JavaScript-to-Dart bridge. This allowed the legacy content to "talk" to our modern Java backend, passing completion data through the bridge as if it were a native part of the app.

4. Seamless Offline Sync

The Problem: Letting users download 2GB of video and then tracking their quiz scores while offline is a synchronization nightmare.

The Solution: We used SQLite on the device to create a local mirror of the user's state. We implemented a "Sync Manager" that uses exponential backoff. When the app detects a stable connection, it replays the user's local actions in an idempotent way, ensuring the backend stays perfectly in sync without duplicating logs.