EliteCode Website

A Project Report

Submitted in partial fulfillments of the requirements

for the award of the degree

of

BACHELOR OF TECHNOLOGY

in

Department of Computer Science and Engineering

by

Akash Rajak (0967CS221007)

Pranav Harode (0967CS221050)

Rishi Chaturvedi (0967CS221061)

Rohit Kumar Singh (0967CS221063)

Yatendra Sharma (0967CS211068)

University Institute of Technology RGPV Shivpuri

Shivpuri – 473551 (Madhya Pradesh, India)

2022-2026
 University Institute of Technology
Gwalior
RGPV Road, Satanwada,
Shivpuri
Mobile-9303782760,9309382761
Email-sitrgpv@[Link]

CANDIDATE’S DECLARATION

I hereby declare that the work, which presented in the Project Report, entitled “EliteCode Website”,
submitted in partial fulfilment of the requirement for the award of the degree of “Bachelor of
Technology” in “Department of Computer Science and Engineering” in the year 2022-2026. The work
has been carried out at University Institute of Technology RGPV, Shivpuri is an authentic report of my
own work carried out under the guidance of “Mrs. Pratibha Chourasiya” (Assistant Professor,
Department of Computer Science and Engineering”). I have not submitted the matter embodied in this
report for award of any other degree or diploma.

Akash Rajak (0967CS221007)

Pranav Harode (0967CS221050)

Rishi Chaturvedi (0967CS221061)

Rohit Kumar Singh (0967CS221063)

Yatendra Sharma (0967CS211068)

I
 University Institute of Technology
Gwalior
RGPV Road, Satanwada,
Shivpuri
Mobile-9303782760,9309382761
Email-
sitrgpv@[Link]

CERTIFICATE
This is to certify that the Project Report titled “EliteCode Website” submitted by Akash Rajak
(0967CS221007), Pranav Harode (0967CS221050), Rishi Chaturvedi (0967CS221061), Rohit Kumar
Singh (0967CS221063) and Yatendra Sharma (0967CS211068) in partial fulfilment of the requirement
for the award of the degree of ‘‘Bachelor of Technology’’ in ‘‘Department of Computer Science and
Engineering” is an original work carried out by him under my guidance and guidance. All Students has
worked for more than one year on the above project work at University Institute of Technology RGPV,
Shivpuri and this has reached the standard fulfilling the requirements and the regulation relating to the
degree.

Mrs. Pratibha Chourasiya

Assistant Professor

Department of Computer Science and Engineering

University Institute of Technology RGPV, Shivpuri

Head of Department External Examiner

II
 ABSTRACT

EliteCode is a web-based coding practice and learning platform designed to help students and programming
enthusiasts enhance their problem-solving and coding skills through an interactive and user-friendly
environment. The platform provides a structured collection of programming challenges covering various
difficulty levels and topics, enabling users to strengthen their understanding of data structures, algorithms,
and programming concepts.

The system offers features such as user authentication, coding challenge management, progress tracking,
submission evaluation, and performance analysis. Users can create accounts, solve coding problems,
monitor their achievements, and improve their skills through continuous practice. The platform is designed
with an intuitive interface that ensures accessibility and ease of use for learners at different levels of
expertise.

The project aims to bridge the gap between theoretical learning and practical implementation by providing
a centralized environment for coding practice and skill development. It encourages logical thinking,
analytical abilities, and efficient programming techniques, which are essential for academic growth and
technical career development.

EliteCode is developed using modern web technologies to ensure scalability, reliability, and responsiveness
across different devices. The platform demonstrates the practical application of software engineering
principles, database management, and web development technologies while delivering an effective learning
experience for users.

In conclusion, EliteCode serves as a comprehensive coding practice platform that supports continuous
learning, self-assessment, and technical skill enhancement, making it a valuable resource for students and
aspiring software professionals.

4
 ACKNOWLEDGMENT

We express our sincere gratitude to all those who have supported and guided us throughout the completion
of this project report.

First, we would like to thank the management and faculty of the University Institute of Technology RGPV,
Shivpuri for providing us with the opportunity and necessary resources to undertake this project. Their
continuous encouragement and academic environment have been invaluable in shaping our work.

We are deeply indebted to our project guide "Mrs. Pratibha Chourasiya" (Assistant Professor, Department
of Computer Science and Engineering), whose guidance, constructive suggestions, and constant support
helped us at every stage of this project. Their expertise in software engineering and system design played a
crucial role in shaping the architecture and successful completion of this work.

We also extend our heartfelt thanks to all the faculty members of our department for their valuable inputs
and encouragement. Their knowledge and experience in distributed systems, web technologies, and
software architecture have greatly contributed to enhancing our understanding of the subject.

We would also like to thank our friends and classmates for their cooperation, motivation, and support
during the course of this project.

Finally, we express our sincere gratitude to our family members for their unwavering support, patience, and
encouragement throughout this journey.

Akash Rajak (0967CS221007)

Pranav Harode (0967CS221050)

Rishi Chaturvedi (0967CS221061)

Rohit Kumar Singh (0967CS221063)

Yatendra Sharma (0967CS211068)

5
ELITECODE WEBSITE
TABLE OF CONTENTS
Title Page No.

Candidate Declaration ii
Certificate iii
Abstract iv
Acknowledgment v
Table of Contents vi–viii
List of Figures ix
List of Tables x
CHAPTER 1: INTRODUCTION 1–8 1.1 Background
of the Problem 1
1.2 Need for the System 2–3
1.3 Existing System vs Proposed System 3–5
1.3.1 Existing System 3–4
1.3.2 Proposed System 4–5
1.4 Scope of the Project 5–6
1.5 Objectives of the Project 7–8
CHAPTER 2: LITERATURE REVIEW 9–15
2.1 Introduction 9
2.2 Existing Platforms 9–13
2.2.1 LeetCode 10
2.2.2 HackerRank 11
2.2.3 Codeforces 11–12
2.2.4 GeeksforGeeks 12–13
2.3 Comparative Analysis 13–14
2.4 Proposed System and Its Advantages 14–15
CHAPTER 3: SYSTEM ANALYSIS 16–26
3.1 Introduction 16
3.2 Functional Requirements 16–20
3.2.1 User Registration and Authentication 17
3.2.2 Problem Catalogue and Browsing 17–18
3.2.3 Code Editing and Execution 18
3.2.4 Submission and Progress Tracking 18–19
3.2.5 AI Assistance and Video Learning 19
3.2.6 Administration 19–20
3.3 Non-Functional Requirements 20–23

3.3.1 Performance 21
3.3.2 Security 21–22
3.3.3 Usability 22
3.3.4 Scalability 22–23
3.3.5 Maintainability 23
3.3.6 Reliability and Availability 23
3.4 Feasibility Study 24–25
3.4.1 Technical Feasibility 24
3.4.2 Economic Feasibility 24–25
3.4.3 Operational Feasibility 25
3.5 Hardware and Software Requirements 25–26
CHAPTER 4: SYSTEM DESIGNING 27–37
4.1 Introduction 27
4.2 System Architecture 27–31
4.2.1 Presentation Layer 28
4.2.2 Application Layer 29
4.2.3 Data Layer 30
4.2.4 External Services Layer 31
4.3 Data Flow Diagrams 31–34
4.4 Entity-Relationship Diagram 34–35
4.5 Database Design 35–36
4.6 Use-Case and Sequence Diagrams 36–37

CHAPTER 5: IMPLEMENTATION 38–46

5.1 Introduction 38
5.2 Technology Stack 38–39
5.3 Backend and Authentication Module 39–41
5.4 Judge0 Code-Execution Module 41–43
5.5 Frontend and Editor Module 43–44
5.6 Admin, AI, and Video Modules 44–46
CHAPTER 6: RESULTS AND DISCUSSION 47–52
6.1 Introduction 47
6.2 Description of Results (Screens) 47–50
6.3 Testing and Validation 50–52
6.4 Discussion 52
CHAPTER 7: FUTURE SCOPE 53–55
CHAPTER 8: CONCLUSION 56–57
References 58
LIST OF FIGURES
Figure No. Figure Title Page No.

Fig. 1 High-Level System Architecture of EliteCode 28

Fig. 2 Three-Tier Architecture Model 30
Fig. 3 Data-Flow Diagram — Level 0 (Context Diagram) 32
Fig. 4 Data-Flow Diagram — Level 1 33
Fig. 5 Data-Flow Diagram — Level 2 (Code Submission) 34
Fig. 6 Entity-Relationship Diagram 35
Fig. 7 Use-Case Diagram 36
Fig. 8 Sequence Diagram — Code Submission and Judging 37
Fig. 9 Flowchart — Code Run / Submit Workflow 40
Fig. 10 Flowchart — Problem Creation with Reference Validation 42
Fig. 11 MERN Stack Technology Overview 39
Fig. 12 Login Page 47
Fig. 13 User Profile and Progress Dashboard 48
Fig. 14 Problem Description Page (Two Sum) 48
Fig. 15 Code Editor with Monaco (C++ Solution) 49
Fig. 16 Admin Panel 50

LIST OF TABLES
Table No. Table Title Page No.

Table 2.1 Comparative Analysis of Existing Coding Platforms 13

Table 3.1 Hardware Requirements 26
Table 3.2 Software Requirements 26
Table 4.1 Users Collection Schema 35
Table 4.2 Problems Collection Schema 36
Table 4.3 Submissions Collection Schema 36
Table 5.1 REST API Endpoints Summary 41
Table 5.2 Judge0 Language Identifiers Used 43
Table 6.1 Representative Test Cases and Results 51
CHAPTER 1

INTRODUCTION
1.1 Background of the Problem
The software industry has witnessed exponential growth in recent years, and with it the
demand for skilled programmers capable of designing correct and efficient solutions to
algorithmic problems. The technical-recruitment process at virtually every product and
service company now revolves around timed coding assessments and live problem-solving
interviews, in which candidates are evaluated on their ability to translate a problem
statement into working code that passes a battery of automated test cases within strict time
and memory limits. This style of evaluation, popularised by online judges, has made
deliberate and repeated practice on coding problems a non-negotiable part of a
computerscience student’s preparation.
Despite the abundance of static learning material — textbooks, blogs, and recorded lectures
— students continue to face a persistent gap between reading about algorithms and
actually implementing, testing, and debugging them. Theoretical understanding of a data
structure or an algorithm does not automatically translate into the ability to write a correct
program that handles edge cases, respects input bounds, and avoids subtle offbyone errors.
These practical skills are acquired only through hands-on practice with immediate,
objective feedback on correctness and performance.
A further difficulty is the fragmentation of the tools a learner must use. A student preparing
for placements typically juggles a local code editor, a website for problem statements, a
separate place to track solved problems, video lectures on a streaming platform, and search
engines or forums for clearing doubts. This fragmentation imposes a significant cognitive
and logistical overhead and disrupts the flow of focused practice. There is no single,
centralised environment that integrates problem discovery, a professional code editor,
automated judging, video editorials, progress tracking, and doubt resolution into a
seamless experience.
Therefore, there is a compelling need for a technology-driven platform that bridges this gap
— a system that provides authentic, automated evaluation of code, integrated learning aids,
and a productive user experience, all within a secure and scalable architecture. EliteCode is
conceived to meet exactly this need.

1.2 Need for the System

The need for the proposed system arises from the limitations of the current, fragmented
approach to programming practice and interview preparation. As the competition for
software roles intensifies, it has become essential for students to adopt a more structured,
data-driven, and technology-enabled approach to building their problem-solving skills.
In the present scenario, a learner attempting to practise must copy a problem statement
from one source, write code in a local IDE, compile and run it against hand-constructed
inputs, and self-assess correctness. Because there is no authoritative hidden test suite, subtle
bugs go undetected and the learner gains false confidence. There is no objective verdict, no
consistent measurement of runtime and memory, and no reliable record of progress over
time.
A well-designed platform must therefore provide automated, sandboxed judging: the
learner’s code should be executed in an isolated environment against a comprehensive set of
hidden test cases, and a verdict should be returned only when every test passes. This
requires safe execution of untrusted code, which a well-architected system delegates to a
dedicated execution service rather than running it directly on the application server.
The system must also provide integrated learning aids. Where a learner is stuck, an
incontext assistant that offers hints and explanations — without simply revealing the answer
— accelerates learning far more effectively than an external search. Similarly, optional video
editorials attached to each problem allow deeper, visual explanation of the underlying
approach.
From an administrative perspective, the platform must allow faculty or content authors to
curate a problem set aligned with the curriculum, with the guarantee that every
published problem is internally consistent. It must also provide progress tracking,
recording every submission and maintaining each learner’s set of solved problems, so that
improvement can be measured and revision planned.
Finally, the system must be secure, responsive, and scalable, protecting user data
through hashed passwords and signed tokens, providing a mobile-friendly interface usable
on the go, and supporting growth in the number of users by externalising the most
resource-intensive operations to managed cloud services. The increasing demand for
reliable, convenient, and effective interview preparation — combined with the limitations
of existing fragmented systems — highlights the urgent need for such a structured,
intelligent, and centralised platform.

1.3 Existing System vs Proposed System

1.3.1 Existing System
In the absence of an integrated platform, a learner’s practice workflow is assembled
manually from disparate tools, and an instructor’s ability to curate practice content is limited.
The existing approach exhibits several drawbacks.
The most significant limitation is the absence of automated, authoritative judging. Without
a hidden test suite, the learner cannot be confident that a solution is correct across edge
cases, nor can performance be measured consistently. Self-assessment with a few hand-
written inputs frequently misses defects that a rigorous judge would catch.
Pricing and access to learning aids on existing commercial platforms is another concern:
the most pedagogically valuable features — detailed editorials, AI hints, and certain
problems — are frequently restricted to paid tiers, limiting access for students with
constrained budgets. Being closed, hosted services, these platforms also cannot be tailored
to a particular institution’s curriculum, nor can faculty author and curate a problem set
aligned with their teaching.
The fragmentation of tools forces constant context-switching between editor, problem
source, progress tracker, and explanation. Where explanations exist, they are often textual
and located on separate pages; few platforms place a context-aware assistant and a video
walkthrough directly alongside the problem-solving workspace. Furthermore, learners
must simply trust that a problem’s expected outputs are correct; the authoring process is
opaque, and there is no transparency into problem integrity. Finally, submissions and
progress data reside with third parties, which may be undesirable for an institution that
wishes to retain ownership of its students’ data.
Overall, the existing approach is fragmented, opaque, and lacks the infrastructure required
for safe, efficient, and trustworthy programming practice.
1.3.2 Proposed System
To overcome these limitations, the proposed solution introduces EliteCode, a centralised,
integrated, full-stack coding platform built on a modern [Link]/Express backend and a
React frontend. The platform integrates all aspects of programming practice — problem
discovery, code editing, automated judging, AI assistance, video learning, and progress
tracking — into a single, seamless system.
The proposed system offers a unified workspace in which the problem statement, a
multilanguage Monaco editor, run/submit controls, results, an AI assistant, a video
editorial, and the submission history are presented together, eliminating tool-switching. It
provides automated, sandboxed judging through the Judge0 engine: user code is
executed against hidden test cases and accepted only when every test passes, with runtime
and memory recorded for each submission.
A key feature is trustworthy authoring. When an administrator creates or updates a problem,
the system executes the supplied reference solutions on Judge0 and refuses to persist the
problem unless they pass the problem’s own tests — guaranteeing internal consistency, an
assurance that even some mature platforms do not expose. The system also embeds
integrated learning aids: a Gemini-powered tutor scoped to the current problem, and per-
problem video editorials stored and streamed through Cloudinary.
Security is enforced through hashed passwords, JWT-based authentication delivered via
HTTP-only cookies, role-based access control, and a Redis-backed mechanism that
invalidates tokens on logout. Because code execution and media storage are externalised to
managed services, the application tier remains lightweight and horizontally scalable. The
result is a secure, transparent, and convenient platform that an institution can host and
control.
1.4 Scope of the Project
The scope of the EliteCode platform, as implemented in this project, is defined as follows.
Within scope. The system supports user registration, login, logout, session validation, and
profile deletion, with two roles — user and admin. It provides a problem catalogue with
filtering by difficulty, topic tag, and solved status, and a problem-solving workspace with a
multi-language Monaco editor, separate Run (visible test cases) and Submit (hidden test
cases) actions, and a results panel. It performs automated execution and judging of code
through Judge0 for C++, Java, and JavaScript, records every submission with its status,
runtime, memory, and per-test statistics, and maintains each user’s solved-problem set. It
offers an AI chat assistant scoped to the current problem, an administrative subsystem for
creating, updating, and deleting problems (including test cases, starter code, and reference
solutions) with end-to-end validation of reference solutions, and a video-learning module
for uploading, streaming, and deleting solution videos. The interface is responsive and
suitable for both desktop and mobile browsers.
Outside scope (current version). The platform does not yet provide real-time, timeboxed
competitive contests with live leaderboards; automated plagiarism or similarity detection;
a peer-to-peer discussion forum; payment or subscription functionality; or support for
languages beyond the three currently integrated. These exclusions are revisited as future
work in Chapter 7.
The project is therefore scoped to deliver a complete and functional interview-preparation
platform that demonstrates the full breadth of modern full-stack web engineering while remaining
achievable within the timeframe of a final-year major project.

1.5 Objectives of the Project

The principal objectives of the EliteCode project are the following:

1. To design and implement a secure authentication and authorisation system using

JSON Web Tokens, password hashing, protected routes, role-based access control,
and a Redis-backed logout mechanism that invalidates tokens before their natural
expiry.
2. To develop a RESTful backend API using [Link] and Express that cleanly separates
authentication, problem management, submission handling, AI interaction, and
video management into well-defined route groups.
3. To design a robust data model in MongoDB using Mongoose, comprising collections
for users, problems, submissions, and solution videos, with appropriate validation,
references, and indexes.
4. To integrate the Judge0 code-execution engine so that user code can be compiled
and executed in multiple languages against both visible and hidden test cases,
producing an accurate verdict with runtime and memory statistics.
5. To build a responsive single-page frontend using React, Redux Toolkit, and Tailwind
CSS, embedding the Monaco editor for a professional multi-language coding
experience.
6. To integrate an AI doubt-solving assistant based on Google Gemini, constrained to act
as a DSA tutor scoped to the current problem.
7. To implement a video-based learning module using signed, direct-to-Cloudinary
uploads and a custom streaming player.
8. To provide a comprehensive administrative dashboard for full CRUD management of
problems and learning content, with validation that prevents the publication of
inconsistent problems.
9. To track user progress by recording every submission and maintaining each user’s
set of solved problems.
10. To test the system thoroughly across unit, integration, and system levels and to
prepare it for deployment.
CHAPTER 2

LITERATURE REVIEW
2.1 Introduction
A literature review is an essential precursor to the design of any non-trivial software system.
By studying the systems that already address a similar need, a designer can identify proven
design patterns, learn from the limitations of existing solutions, and clearly articulate the
gap that the proposed system intends to fill. This chapter surveys the landscape of online
coding and interview-preparation platforms, examines the most prominent of them in
detail, compares them across a set of relevant dimensions, and establishes the advantages of
the proposed EliteCode platform.

2.2 Existing Platforms

Several well-established platforms serve the broad goal of programming practice and
interview preparation. The most influential of these were studied in detail, and the design
ideas they embody were evaluated for adoption.
2.2.1 LeetCode
LeetCode is among the most widely used platforms for technical-interview preparation. It
offers a large, well-curated catalogue of algorithmic problems organised by difficulty and
topic, an in-browser editor, automated judging against hidden test cases, official and
community editorials, a discussion section, and a contest mode. Its strengths lie in the
quality and breadth of its problem set and the realism of its judging. Many of its most
valuable resources — detailed editorials, certain problems, and debugging features — are,
however, restricted to paid subscribers. EliteCode draws its core interaction model
(problem list → editor → run/submit → verdict) directly from this style of platform, and
additionally embeds an AI tutor and video editorials that LeetCode largely reserves for its
premium tier.
2.2.2 HackerRank
HackerRank targets both individual learners and corporate recruiters. In addition to
practice problems organised into skill tracks and certifications, it provides an assessment
platform used by companies to screen candidates. It supports a wide range of languages
and includes domain-specific tracks such as SQL and functional programming. Its dual
focus on learning and recruitment makes it broad but, for a pure self-practice use case,
somewhat heavyweight. The lesson drawn for EliteCode is the value of organising problems
by topic and difficulty and of presenting clear, immediate feedback.
2.2.3 Codeforces
Codeforces is oriented towards competitive programming. Its defining feature is regular,
rated online contests with a sophisticated rating system, after-contest editorials, and a
strong community. It demonstrates the importance of a reliable, high-throughput judge and
a large problem bank. However, it is less focused on the structured, topic-wise interview
preparation that EliteCode targets, and its interface is optimised for contests rather than
for guided learning. Its contest model nonetheless informs the future-scope plan for a
contest module in EliteCode.
2.2.4 GeeksforGeeks
GeeksforGeeks is primarily a content platform — articles, tutorials, and explanations —
with an attached practice section. Its strength is the breadth of its explanatory material; its
practice and judging experience is generally considered less polished than that of dedicated
judges. It illustrates the value of pairing problems with high-quality explanatory content,
an idea that EliteCode operationalises through its integrated AI tutor and per-problem
video editorials.
Across all of these systems, three architectural ideas recur and were adopted as proven
patterns: a clear separation between a visible/sample set of test cases shown to the user and
a hidden set used for the final verdict; the delegation of untrusted code execution to a
sandboxed, isolated execution service; and the persistence of every submission to support
history, progress tracking, and analytics.

2.3 Comparative Analysis

Table 2.1 compares the studied platforms, and the proposed EliteCode system, across
dimensions relevant to the objectives of this project.
Table 2.1 — Comparative Analysis of Existing Coding Platforms

Feature / EliteCode
Platform LeetCode HackerRank Codeforces GeeksforGeeks (Proposed)

Automated judging Yes Yes Yes Partial Yes

(hidden tests)

In-browser Yes Yes Basic Basic Yes (Monaco)

professional editor

Multiple language Yes Yes Yes Yes Yes (C++, Java,

support JS)
Topic / difficulty Yes Yes Partial Yes Yes filtering
Integrated AI doubt Paid No No No Yes (Gemini) assistant
Per-problem video Paid No No Partial Yes
editorials (Cloudinary)
Submission history Yes Yes Yes Partial Yes
& progress
Admin Internal Internal Internal — Yes (full
problemauthoring CRUD) panel
Referencesolution Internal Internal Internal — Yes (Judge0)
validation on create

Open / selfhostable No No No No Yes

Cost to learner Freemium Freemium Free Freemium Free

The comparison shows that while individual capabilities of EliteCode exist in one or more
commercial platforms, the combination of an integrated AI tutor, per-problem video
editorials, a full administrative authoring panel with automatic reference-solution
validation, and self-hostability in a single free application constitutes a distinctive and
useful contribution.

2.4 Proposed System and Its Advantages

From the survey, the limitations of existing systems — relative to the needs of a self-hosted,
learning-focused institutional platform — are clear: pedagogically valuable aids are often
paywalled; closed platforms cannot be customised to a curriculum; learning aids are
fragmented; problem integrity is opaque; and student data resides with third parties.
The proposed EliteCode platform addresses each of these. It is integrated, combining
problem solving, judging, AI help, and video learning in one screen; open and selfhostable,
giving an institution full control over content and data; free for learners; and trustworthy
by construction, guaranteeing that every published problem is internally consistent
through automatic reference-solution validation. It reproduces the proven, judge-style
interaction model of the leading platforms while adding an embedded AI tutor, per-problem
video editorials, and a transparent authoring workflow — all on a freely deployable MERN-
stack foundation. These advantages position EliteCode as a practical, modern, and
pedagogically valuable alternative for institutional use.

CHAPTER 3
SYSTEM ANALYSIS
3.1 Introduction
System analysis is the process of studying a problem domain in order to specify the
requirements and behaviour of a proposed software system. This chapter analyses the
requirements of the EliteCode platform, enumerating its functional and non-functional
requirements, assessing its feasibility along technical, economic, and operational
dimensions, and stating the hardware and software prerequisites. The analysis presented
here forms the foundation on which the system design of Chapter 4 is built.

3.2 Functional Requirements

The functional requirements specify what the system must do. They are organised by
module.
3.2.1 User Registration and Authentication
The system shall allow a new user to register with first name, last name, email, age, and a
strong password, validating the inputs on both the client and the server. Passwords shall be
hashed using bcrypt before storage and never kept in plaintext. The system shall
authenticate a user by email and password and issue a signed JSON Web Token delivered
via an HTTP-only cookie. It shall validate an existing session and return the authenticated
user’s details, and it shall log a user out by invalidating the active token via a Redis blocklist
with a time-to-live equal to the token’s remaining lifetime. A user shall be able to delete
their own profile, with the deletion cascading to the user’s submissions.
3.2.2 Problem Catalogue and Browsing
The system shall display a list of all problems showing title, difficulty, and tags, and shall
allow filtering by difficulty (easy/medium/hard), tag (array/linkedList/graph/dp), and
solved status. It shall indicate which problems the current user has already solved, and
shall display a full problem — including description, visible test cases, and starter code —
when one is selected.
3.2.3 Code Editing and Execution
The system shall provide an in-browser editor supporting C++, Java, and JavaScript, loading
language-specific starter code. It shall allow a user to Run code against the visible test cases
and view per-case output, and to Submit code for evaluation against hidden test cases. It
shall compute a verdict (accepted/wrong/error) together with runtime, memory, and the
count of test cases passed.
3.2.4 Submission and Progress Tracking
The system shall persist every submission with its code, language, status, runtime, memory,
and test statistics. On an accepted submission, it shall add the problem to the user’s solved
set without duplication. It shall display a user’s submission history for a problem, including
the code of each attempt and its associated statistics.
3.2.5 AI Assistance and Video Learning
The system shall provide a chat interface, scoped to the current problem, that forwards the
conversation and the problem context to the Gemini model and returns its response, with
the assistant constrained to act as a DSA tutor for the current problem. It shall allow an
administrator to upload a solution video for a problem via a signed, direct-to-Cloudinary
upload, store the video metadata, stream the editorial to users through a custom player,
and delete a video from both Cloudinary and the database.
3.2.6 Administration
The system shall allow an administrator to create a problem with description, difficulty,
tags, visible and hidden test cases, starter code, and reference solutions; to update and
delete problems; and to manage learning content. It shall validate reference solutions on
Judge0 before persisting a created or updated problem, and shall restrict all administrative
endpoints to users with the admin role.

3.3 Non-Functional Requirements

The non-functional requirements specify how well the system performs its functions.
3.3.1 Performance
The catalogue and problem pages shall load within a few seconds on a broadband
connection. Judge0 results shall be retrieved through an efficient polling mechanism with a
bounded one-second interval, ensuring that verdicts are returned promptly once execution
completes. Database queries shall be supported by appropriate indexes, including a
compound index on submissions by user and problem.
3.3.2 Security
Passwords shall be hashed with bcrypt; JWTs shall be transmitted in HTTP-only cookies to
mitigate cross-site scripting risks; access control shall be enforced through dedicated
middleware with role checks; tokens shall be revocable via a Redis blocklist on logout; all inputs
shall be validated on the server; and CORS shall be restricted to the known frontend origin with
credentials enabled. Untrusted user code shall never execute on the application server; it shall
be delegated entirely to the sandboxed Judge0 service.
3.3.3 Usability
The interface shall be clean, modern, and responsive, usable on desktop and mobile
browsers. It shall centre the experience on a familiar, VS-Code-like editor and shall present
clear verdicts and informative error messages. Forms shall provide inline, real-time
validation feedback.
3.3.4 Scalability
The application tier shall be stateless, with session state carried in signed tokens, so that it
can be scaled horizontally behind a load balancer. The most resource-intensive operations
— code execution and media storage/streaming — shall be externalised to managed
services (Judge0 and Cloudinary), keeping the application servers lightweight and allowing
each subsystem to scale independently.
3.3.5 Maintainability
The codebase shall be organised into clear, modular layers — routes, controllers, models,
middleware, and utilities on the backend, and pages, components, store, and utilities on the
frontend. A uniform JavaScript language across all tiers shall reduce context-switching and
encourage code reuse.
3.3.6 Reliability and Availability
Published problems shall be guaranteed internally consistent through reference-solution
validation, and all submissions shall be durably persisted. By depending on managed
services for the database, cache, execution, and media, the system shall inherit the high
availability of those services for the corresponding subsystems.

3.4 Feasibility Study

A feasibility study evaluates whether the proposed system is worth developing along
technical, economic, and operational dimensions.
3.4.1 Technical Feasibility
The system is built entirely from mature, well-documented, and freely available
technologies. The MERN stack is a proven combination for full-stack web applications. Code
execution, AI, and media handling are delegated to established external services (Judge0,
Google Gemini, Cloudinary) that expose stable interfaces, eliminating the need to build
complex, security-sensitive subsystems — such as a sandboxed code executor — from
scratch. The team’s familiarity with JavaScript across all tiers reduces technical risk. The
project is therefore technically feasible.
3.4.2 Economic Feasibility
Development relies exclusively on open-source software and the free tiers of the external
services, incurring no licensing cost. The only potential recurring costs are for hosting and
for usage of the external APIs beyond their free quotas, both of which are modest and scale
with usage. Given the negligible development cost and the high educational and practical
value of the outcome, the project is economically feasible.
3.4.3 Operational Feasibility
The system targets a well-understood user base — students and instructors — whose
platforms, so users require little training, and administrators operate through a guided,
form-based panel. The project is therefore operationally feasible.

3.5 Hardware and Software Requirements

Table 3.1 — Hardware Requirements

Component Development (minimum) Server / Deployment (recommended)

Processor Dual-core 2.0 GHz Quad-core 2.5 GHz or higher

RAM 4 GB 8 GB or higher
Storage 10 GB free 20 GB+ (SSD preferred)
Network Broadband internet Stable high-bandwidth connection
Client Any device with a modern browser — Table
3.2 — Software Requirements

Category Software / Tool

Operating System Windows 10/11, Linux, or macOS

Runtime [Link] (LTS) and npm
Database MongoDB (local or MongoDB Atlas)
Cache / Token store Redis (local or Redis Cloud)
Frontend toolchain Vite, React 19, Redux Toolkit, Tailwind CSS, DaisyUI
Editor library Monaco Editor (@monaco-editor/react)
Backend framework [Link] 5, Mongoose 8
External services Judge0 CE API, Google Gemini API, Cloudinary
Browser Google Chrome / Mozilla Firefox / Microsoft Edge (latest)
Version control Git and GitHub
Development IDE Visual Studio Code
API testing Postman / Thunder Client

CHAPTER 4

SYSTEM DESIGNING
4.1 Introduction
System design translates the requirements established in the previous chapter into a
concrete architectural and structural blueprint for the software. This chapter presents the
the conceptual data model as an entity-relationship diagram; the concrete database design
as a set of MongoDB collections; and the externally visible behaviour as use-case and
sequence diagrams. Together these views constitute a complete design from which the
implementation directly follows.

4.2 System Architecture

EliteCode follows a classical three-tier, client–server architecture augmented with
external service integrations, as shown in Fig. 1.
Fig. 1 — High-Level System Architecture of EliteCode

┌─────────────────────────────────────────────────────────────────────
─┐
│ CLIENT TIER (Browser)
│
│ React 19 SPA · Redux Toolkit · Tailwind/DaisyUI · Monaco Editor
│
│ Pages: Homepage, Login, Signup, ProblemPage, Admin
│
│ Components: AdminPanel, AdminUpload, ChatAi, Editorial, History
│
└───────────────────────────────┬─────────────────────────────────────
─┘
│ HTTPS / REST (JSON, axios)
│ HTTP-only JWT cookie
▼

┌─────────────────────────────────────────────────────────────────────
─┐
│ APPLICATION TIER ([Link] + Express)
│ Routers: /user /problem /submission /ai /video
│
│ Middleware: userMiddleware (JWT) · adminMiddleware (JWT +
role) │
│ Controllers: auth · problem · submission · video · solveDoubt
│
│ Utilities: problemUtility (Judge0) · validator
│
└───────┬───────────────┬───────────────┬───────────────┬─────────────
─┘
│ │ │ │
▼ ▼ ▼ ▼
 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌──────────────────┐
│ MongoDB │ │ Redis │ │ Judge0 CE │ │ Gemini AI / │
│ (Mongoose) │ │ (token │ │ (code │ │ Cloudinary │
│ users, │ │ blocklist) │ │ execution) │ │ (AI / video) │
│ problems, │ │ │ │ │ │ │
│ submissions,│ │ │ │ │ │ │
│ videos │ │ │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
└──────────────────┘ DATA TIER · EXTERNAL SERVICES

4.2.1 Presentation Layer

The presentation layer is a React single-page application that renders the entire user
interface. It is composed of route-level pages (Homepage, Login, Signup, ProblemPage,
Admin) and reusable components (AdminPanel, AdminUpload, AdminDelete, AdminVideo,
ChatAi, Editorial, SubmissionHistory). Global authentication state is held in a Redux store
and shared across components, while local UI state (such as the active editor tab or the
current code) is held within components. All communication with the backend is
performed asynchronously through an axios client configured to send the HTTP-only JWT
cookie with every request. Styling is provided by Tailwind CSS and DaisyUI for a consistent,
responsive appearance, and the Monaco editor provides the code-editing surface.
4.2.2 Application Layer
The application layer is a stateless Express server. Incoming requests are routed by URL prefix
to one of five routers — /user, /problem, /submission, /ai, and /video. Requests to
protected endpoints pass through authentication/authorisation middleware:
userMiddleware verifies the JWT and confirms the user exists and the token is not
revoked, while adminMiddleware additionally requires the admin role. Controllers
contain the business logic for each domain — authentication, problem management,
submission handling, AI interaction, and video management — and cross-cutting concerns
such as code execution and input validation are factored into utility modules. This layer
orchestrates all interactions between the client, the database, and the external services.
4.2.3 Data Layer
The data layer comprises MongoDB, accessed through the Mongoose ODM, for primary
persistence, and Redis for the JWT blocklist. MongoDB stores four collections — users,
problems, submissions, and solution-videos — whose schemas are described in Section 4.5.
Mongoose provides schema validation, references between collections, a compound index
on submissions, and middleware such as the cascade-on-delete hook that removes a user’s
submissions when the user is deleted. Redis stores revoked tokens as expiring keys, enabling
immediate logout.
4.2.4 External Services Layer
Beyond the core tiers, the system integrates three external services. Judge0 compiles and
executes user code in a secure sandbox and returns per-test status, output, runtime, and
memory. Google Gemini, accessed through the @google/genai SDK, powers the in-context
AI tutor. Cloudinary stores and streams solution videos, with uploads performed directly
from the browser using a signed payload so that large files never traverse the application
server. This externalisation isolates the most resource-intensive and security-sensitive
operations from the application tier.

4.3 Data Flow Diagrams

Data-flow diagrams (DFDs) model the system as a network of processes that transform
data flowing between external entities and data stores. They are presented here at three
levels of increasing detail.

Fig. 3 — DFD Level 0 (Context Diagram)

 chat queries AI
replies, videos

┌──────┐ ───────────────────▶ ┌───────────────────┐

─────────────────▶ ┌──────┐
│ USER │ │ ELITECODE │
│ USER │
└──────┘ ◀─────────────────── │ PLATFORM (0) │
◀───────────────── └──────┘
└───────────────────┘
┌───────┐ problem CRUD, ▲ │ results
│ ADMIN │ video mgmt ───────────▶ │ │◀──────────────▶
┌──────────┐
└───────┘ │ ▼ │
Judge0 │
│ external │
Gemini │
└─────────────────────
│Cloudinary│

└──────────┘

At the context level, the EliteCode platform is a single process exchanging data with two
human external entities — User and Admin — and with the external service providers.
Fig. 4 — DFD Level 1
┌──────┐ ┌────────────────────┐
│ USER │──register/login──────────────────▶│ 1.0 Authentication │──▶
(D1) Users
└──────┘◀──JWT cookie──────────────────────│ & Sessions
│◀── │
└────────────────────┘
│ browse / filter ┌────────────────────┐
├────────────────────────────────────────│ 2.0 Problem │──▶
(D2) Problems
│◀──problem list / detail─────────────────│ Catalogue │◀──
│
└────────────────────┘ │ run / submit code
┌────────────────────┐ ┌────────┐
├────────────────────────────────────────│ 3.0 Code Execution │────▶│
Judge0 │
│◀──verdict, runtime, memory──────────────│ & Judging
│◀────└────────┘
 │ └──▶ (D3)
Submissions
│ ask doubt ┌────────────────────┐
┌────────┐
├────────────────────────────────────────│ 4.0 AI Assistant │────▶│
Gemini │
│◀──AI response───────────────────────────│
│◀────└────────┘
│ watch editorial ┌────────────────────┐
┌──────────┐
└────────────────────────────────────────│ 5.0 Video Learning
│───▶│Cloudinary│
│
│◀───└──────────┘
┌───────┐ manage problems / videos └─────────┬──────────┘ │ ADMIN
│──────────────────────────────────────────────┴──▶ (D4) SolutionVideos
└───────┘

Level 1 decomposes the platform into five processes — Authentication, Problem Catalogue,
Code Execution & Judging, AI Assistant, and Video Learning — and four data stores: D1
Users, D2 Problems, D3 Submissions, and D4 Solution-Videos.
Fig. 5 — DFD Level 2 (Code Submission Process)
┌──────┐ code + language + problemId ┌──────────────────────────┐
│ USER │ ──────────────────────────────▶│ 3.1 Create pending │──▶
(D3) Submissions
└──────┘ │ submission record │
└────────────┬─────────────┘
▼
fetch hidden tests ┌──────────────────────────┐ (D2)
Problems ─────────▶│ 3.2 Build Judge0 batch │
│ (source, lang, stdin, │
│ expected_output) │
└────────────┬─────────────┘
▼
┌──────────────────────────┐
tokens ┌────────┐
│ 3.3 Submit batch & poll │
────────▶ │ Judge0 │
│ until status > 2 │
◀──────── └────────┘
└────────────┬─────────────┘
results
 ▼
┌──────────────────────────────────────────┐
│ 3.4 Compute verdict (accepted/wrong/error),│──▶ update (D3)
│ runtime, memory, testCasesPassed
│──▶ update (D1) solved set

└────────────────────┬───────────────────────┘
▼
┌──────────┐
│ USER │ verdict +
statistics
└──────────┘

Level 2 expands the central Code Execution & Judging process, showing the creation of a
pending submission, the construction of the Judge0 batch from the problem’s hidden test
cases, the submit-and-poll cycle, and the final computation and persistence of the verdict.

4.4 Entity-Relationship Diagram

The conceptual data model comprises four principal entities — User, Problem,
Submission, and SolutionVideo — related as shown in Fig. 6.
Fig. 6 — Entity-Relationship Diagram
┌─────────────────┐
┌──────────────────────┐
│ USER │ │ PROBLEM
│
├─────────────────┤
├──────────────────────┤
│ _id (PK) │ creates (1:N) │ _id (PK)
│
│ firstName │────────────────────────▶│ title
│
│ lastName │ problemCreator │ description
│
│ emailId (U) │ │ difficulty
│
│ age │ │ tags
│
│ role │ │
visibleTestCases[] │
│ password │ │
hiddenTestCases[] │
│ problemSolved[] │◀───── solves(M:N────▶│ startCode[]
│
└────────┬────────┘ │
referenceSolution[] │
 │ │ problemCreator
(FK) │
│ makes (1:N)
└──────────┬───────────┘
▼ │ has
(1:N)
┌─────────────────┐ targets (N:1) │
│ SUBMISSION │───────────────────────────────────▶│
├─────────────────┤ ▼
│ _id (PK) │
┌──────────────────────┐
│ userId (FK) │ │ SOLUTION_VIDEO
│
│ problemId (FK) │
├──────────────────────┤
│ code │ for (1:1 / 1:N) │ _id (PK)
│
│ language │◀────────────────────────│ problemId (FK)
│
│ status │ │ userId (FK) │
│ runtime │ │ cloudinaryPublicId(U)│
│ memory │ │ secureUrl │
│ testCasesPassed │ │ thumbnailUrl │
│ testCasesTotal │ │ duration │
└─────────────────┘ └──────────────────────┘

Legend: PK = Primary Key FK = Foreign Key (reference) U = Unique

[] = embedded array of sub-documents

A User (admin) creates many Problems; a User solves many Problems and a Problem is
solved by many Users; a User makes many Submissions, each targeting exactly one
Problem; and a Problem has one or more SolutionVideos, each uploaded by one admin
user.

4.5 Database Design

EliteCode uses MongoDB, a document database. The conceptual entities are realised as four
collections. Embedded arrays of sub-documents (test cases, starter code, reference
solutions) are used where data is tightly owned by a parent document, while references are
used across collection boundaries. The schemas below reflect the actual Mongoose models
of the system.
Table 4.1 — Users Collection (user) Schema

Field Type Constraints / Notes

_id ObjectId Primary key (auto-generated) firstName String

Required, length 3–20 lastName String Length 3–20 emailId
String Required, unique, trimmed, lowercase, immutable
age Number Range 6–80
role String Enum {user, admin}, default user
problemSolved [ObjectId] References to problem; no duplicates password
String Required; stored as a bcrypt hash
createdAt, updatedAt Date Mongoose timestamps Table
4.2 — Problems Collection (problem) Schema

Field Type Constraints / Notes

_id ObjectId Primary key title String Required

description String Required
difficulty String Enum {easy, medium, hard}, required
tags String Enum {array, linkedList, graph, dp},
required
visibleTestCases [{ input, output, Each field required; shown to user explanation }]
hiddenTestCases [{ input, output }] Each field required; used for verdict
startCode [{ language, initialCode }] Per-language starter template
referenceSolution [{ language, completeCode Validated on Judge0 before save
}]
problemCreator ObjectId Reference to user, required
Table 4.3 — Submissions Collection (submission) Schema

Field Type Constraints / Notes

_id ObjectId Primary key

userId ObjectId Reference to user, required problemId ObjectId
Reference to problem, required code String Required; submitted source
code language String Enum {javascript, c++, java}, required status
String Enum {pending, accepted, wrong, error}, default pending
runtime Number Milliseconds, default 0 memory
Number Kilobytes, default 0 errorMessage String
Default empty testCasesPassed Number
Default 0 testCasesTotal Number Default 0
createdAt, updatedAt Date Mongoose timestamps

A compound index on { userId, problemId } accelerates the common query for a user’s
submissions to a particular problem. The solution-videos collection stores problemId and
userId references, a unique cloudinaryPublicId, the secureUrl, an optional
thumbnailUrl, and the duration in seconds.

4.6 Use-Case and Sequence Diagrams

Fig. 7 depicts the principal use cases and the actors that participate in them; the Admin actor
generalises the User actor, inheriting all user use cases in addition to the administrative
ones.
Fig. 7 — Use-Case Diagram
ELITECODE PLATFORM
┌───────────────────────────────────────────────────────────────┐
│ (Register) (Login) (Logout) │
│ (Browse/Filter Problems) (View Problem) │
│ (Run Code) (Submit Code) (View Submission History) │
│ (Track Progress) (Ask AI Tutor) (Watch Editorial Video) │
│ │
│ ─────────────── admin-only ─────────────── │
│ (Create Problem) (Update Problem) (Delete Problem) │
│ (Upload Video) (Delete Video) (Register Admin) │
└───────────────────────────────────────────────────────────────┘
▲ ▲
│ │
┌──┴───┐ ┌───┴───┐
│ USER │ │ ADMIN │
(inherits all USER use cases)
└──────┘ └───────┘

Fig. 8 captures the time-ordered interaction for the most important scenario — code
submission and judging.
Fig. 8 — Sequence Diagram: Code Submission and Judging
User ProblemPage Express(submit) MongoDB Judge0
│ Submit │ │ │ │
│──────────▶│ POST /submission/submit/:id │ │
│ │─────────────────▶│ create pending submission │
│ │ │─────────────▶│ │
│ │ │ load hidden test cases │
│ │ │◀─────────────│ │
│ │ │ submitBatch(source,lang,io) │
│ │ │────────────────────────────▶│
│ │ │◀──────── tokens ─────────────│
│ │ │ poll submitToken (status>2) │
│ │ │────────────────────────────▶│
│ │ │◀──── results (status,time,mem)
│ │ │ compute verdict, update sub │
│ │ │─────────────▶│ update solved set
│ │◀── verdict,stats │ │ │
│◀──────────│ │ │ │

CHAPTER 5
IMPLEMENTATION
5.1 Introduction
This chapter describes how the design presented in Chapter 4 was realised as working
software. It first details the technology stack and then describes the implementation of the
system module by module — the backend and authentication subsystem, the Judge0
codeexecution module, the frontend and editor module, and the administrative, AI, and
video modules — relating each to the concrete files, REST endpoints, and data schemas of
the system. The implementation followed an incremental, phase-wise methodology in which
the backend foundation was established first, followed by code execution, the frontend, the
editor, the admin panel, AI integration, the video module, and finally testing and
deployment.

5.2 Technology Stack

EliteCode is implemented on the MERN stack with a set of supporting libraries and external
services, as summarised in Fig. 11.
Fig. 11 — MERN Stack Technology Overview
┌───────────────────────────────────────────────────────────┐
│ FRONTEND React 19 · Redux Toolkit · React Router 7 │
│ Tailwind CSS 4 · DaisyUI · Monaco Editor
│ │ react-hook-form · zod · axios · lucide-
react │
├───────────────────────────────────────────────────────────┤
│ BACKEND [Link] · Express 5 · Mongoose 8 │
│ jsonwebtoken · bcrypt · validator │
│ cookie-parser · cors │
├───────────────────────────────────────────────────────────┤
│ DATA MongoDB · Redis │
├───────────────────────────────────────────────────────────┤
│ SERVICES Judge0 CE · Google Gemini · Cloudinary │
└───────────────────────────────────────────────────────────┘

On the frontend, React provides the component model; Redux Toolkit manages global
authentication state; React Router defines the route table; Tailwind CSS and DaisyUI
provide styling; Monaco provides the code-editing surface; react-hook-form with zod
validates forms; and axios performs all HTTP communication with credentials enabled. On
the backend, Express defines the HTTP server and routing; Mongoose models and
validates documents; jsonwebtoken and bcrypt implement authentication; validator
performs server-side input checks; and cookie-parser and cors provide middleware.
MongoDB stores all primary data, Redis maintains the JWT blocklist, and the external
services Judge0, Gemini, and Cloudinary provide execution, AI, and media respectively.
5.3 Backend and Authentication Module
The backend foundation comprises the Express server, the database connections, the data
models, the authentication subsystem, and the middleware.
The application entry point configures CORS to accept credentialed requests from the
frontend origin, registers the JSON-body and cookie-parser middleware, mounts the five
routers under their URL prefixes (/user, /problem, /submission, /ai, /video), and then
initialises the MongoDB and Redis connections in parallel before beginning to listen. The
MongoDB connection targets the leetcode database through Mongoose.
The four Mongoose schemas described in Section 4.5 were defined with their validations,
enumerations, references, the compound submission index, and the cascade-on-delete
hook on the user schema. The userAuthent controller implements registration, login,
logout, admin registration, and profile deletion. Registration validates the request body
using the validator utility, hashes the password with bcrypt, persists the user (forcing
the user role), signs a JWT carrying { _id, emailId, role } valid for one hour, and
returns it via an HTTP-only cookie. Login verifies the credentials and re-issues a token;
logout adds the current token to a Redis blocklist with a TTL equal to its remaining lifetime,
so the token is rejected on subsequent use even before it expires.
Two middleware modules enforce access control. userMiddleware extracts and verifies the
JWT from the cookie, confirms the corresponding user exists, and checks that the token is
not present in the Redis blocklist before attaching the user to the request.
adminMiddleware performs the same checks and additionally requires the token’s role to be
admin. The complete set of REST endpoints is summarised in Table 5.1.

Table 5.1 — REST API Endpoints Summary

Method Endpoint Access Description

POST /user/register Public Register a new user; sets cookie

POST /user/login Public Authenticate; sets cookie
POST /user/logout User Invalidate token via Redis
blocklist
POST /user/admin/register Admin Register a new administrator
DELETE /user/deleteProfile User Delete own account (cascades)
GET /user/check User Validate session; return current
user
POST /problem/create Admin Create problem (validates
references)
PUT /problem/update/:id Admin Update problem (re-validates
references)
 GET /problem/problemById/:id User Fetch a problem (with video data)
GET /problem/getAllProblem User List all problems
GET /problem/problemSolvedByUser User List the user’s solved problems
GET /problem/submittedProblem/:pid User Submission history for a problem
POST /submission/submit/:id User Submit code (hidden tests,
graded)
POST /submission/run/:id User Run code (visible tests)
POST /ai/chat User Ask the Gemini DSA tutor
GET /video/create/:problemId Admin Get a signed Cloudinary upload
payload
POST /video/save Admin Save uploaded-video metadata
DELETE /video/delete/:problemId Admin Delete a video (Cloudinary + DB)
5.4 Judge0 Code-Execution Module
Automated code execution is implemented by integrating the Judge0 CE engine through the
problemUtility module, on top of which the submission subsystem is built.

Three helper functions encapsulate the integration. getLanguageById maps a language

name to a Judge0 numeric identifier (Table 5.2). submitBatch posts a batch of submissions
— each a tuple of source code, language id, standard input, and expected output — to the
Judge0 batch endpoint and returns an array of tokens. submitToken polls the batch-results
endpoint with those tokens at one-second intervals until every submission has reached a
terminal state (status id greater than 2), then returns the full results, including per-test
status, output, time, and memory.
Table 5.2 — Judge0 Language Identifiers Used

Language Judge0 language_id

C++ 54
Java 62
JavaScript 63

The userSubmission controller exposes two operations. runCode executes the user’s
code against the problem’s visible test cases and returns the per-case output for display in
the editor. submitCode first creates a pending submission record, then executes the code
against the problem’s hidden test cases; once results are available it determines the verdict
— accepted only if every hidden test passes (status id 3), otherwise wrong or error —
records the runtime, memory, and number of test cases passed, updates the submission,
and, on acceptance, adds the problem to the user’s problemSolved set without
duplication. The control logic of this workflow is depicted in Fig. 9.
 ┌─────────┐
│ Start │
└────┬────┘
▼
┌──────────────────────┐
│ User clicks Run/Submit│
└──────────┬───────────┘
▼
┌──────────────────────┐
│ Select test set: │
│ Run→visible │
│ Submit→hidden │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ Map language → id │
│ (c++54,java62,js63) │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ submitBatch to Judge0 │
└──────────┬───────────┘
▼
┌──────────────────────┐ not done
│ Poll tokens; all │───────────┐
│ status_id > 2 ? │◀──────────┘ wait 1s
└──────────┬───────────┘
yes ▼
┌──────────────────────┐ any fail ┌──────────────────────┐
│ All test cases │───────────▶│ status = wrong/error │
│ accepted (id==3)? │ no │ record stats
│ └──────────┬───────────┘
└──────────┬───────────┘ yes ▼
│ ┌──────────────────────┐ │
│ status = accepted; │ │
│ add to solved set │ │
└──────────┬───────────┘ │
▼◀───────────────────────────────────┘
┌──────────────────────┐
│ Return verdict+stats │
└──────────┬───────────┘
▼
┌───────┐
│ End │
└───────┘
5.5 Frontend and Editor Module
The frontend is a React single-page application bootstrapped in [Link], which wraps the
application in the Redux Provider and the router. [Link] defines the route table and the
protection rules: the homepage and problem pages require authentication; the login and
signup routes redirect already-authenticated users away; and the admin routes require the
admin role. On load, the app dispatches a checkAuth thunk that calls /user/check to
restore the session from the cookie.
The Redux store is configured with a single auth slice that defines the registerUser,
loginUser, checkAuth, and logoutUser async thunks — each wrapping the
corresponding API call — and reducers that update user, isAuthenticated, loading,
and error across the pending/fulfilled/rejected lifecycle. The axiosClient utility
centralises the base URL and enables withCredentials so the JWT cookie travels with
every request. The Login and Signup pages use react-hook-form with zod schemas to
validate inputs on the client, and the Homepage fetches the full problem list and the user’s
solved problems, rendering them as a card grid with client-side filters by difficulty, tag, and
solved status.
The problem-solving workspace, implemented in ProblemPage, is organised as a two-panel
layout. The left panel offers tabbed views — Description, Editorial (the solution video),
Solutions (the reference solutions per language), Submissions (the user’s history), and
ChatAI (the AI tutor). The right panel hosts the Monaco editor with a language selector (C+
+, Java, JavaScript) that loads the corresponding starter code, configured with a dark theme,
line numbers, and word wrapping, alongside the Testcase and Result views. Run calls
/submission/run/:id and renders per-case results; Submit calls
/submission/submit/:id and renders the verdict and statistics. The SubmissionHistory
component fetches and tabulates past attempts with colour-coded statuses and a modal
viewer for each attempt’s code.

5.6 Admin, AI, and Video Modules

Administration. The Admin page presents the management options. The AdminPanel
component provides the problem-creation form, built with react-hook-form and zod,
capturing the title, description, difficulty, tags, dynamic arrays of visible and hidden test
cases, and the starter code and reference solutions for all three languages; on submission it
calls /problem/create. Crucially, the backend validates the submitted reference solutions
on Judge0 before persisting, so an inconsistent problem cannot be published — the logic
shown in Fig. 10. The AdminDelete component lists problems and deletes a selected
problem after confirmation, and update operations follow the same validate-then-persist
pattern.
Fig. 10 — Flowchart: Problem Creation with Reference Validation
┌─────────┐
│ Start │
 ┌──────────────────────┐
│ Admin submits problem │
│ (tests, startCode, │
│ referenceSolution) │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ For each reference │
│ solution: build batch │
│ vs visible test cases │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ Submit to Judge0, │
│ poll for results │
└──────────┬───────────┘
▼
┌──────────────────────┐ no ┌──────────────────────────┐
│ All reference results │─────▶│ Reject: return error, │
│ accepted (id==3)? │ │ do NOT save problem │
└──────────┬───────────┘ └──────────────────────────┘
yes ▼
┌──────────────────────┐
│ Persist problem to │
│ MongoDB │
└──────────┬───────────┘
▼
┌───────┐
│ End │
└───────┘

AI integration. On the backend, the solveDoubt controller (mounted at /ai/chat)

receives the conversation history together with the current problem’s context — title,
description, test cases, and starter code — and forwards them to Google’s Gemini model
through the @google/genai SDK. A carefully written system instruction constrains the
model to behave strictly as a Data-Structures-and-Algorithms tutor for the specific problem
at hand. On the frontend, the ChatAi component renders a multi-turn chat interface,
maintains the message list in the role/parts format expected by the model, auto-scrolls to
the latest message, sends the problem context with each query, and gracefully handles
errors.
Video learning. To avoid routing large video files through the application server, uploads
are performed directly from the browser to Cloudinary using a signed payload. The
generateUploadSignature controller verifies the problem exists, constructs a
deterministic public identifier, and returns a signature, timestamp, API key, and upload
resulting secure URL, thumbnail, and duration. On the learner’s side, the Editorial
component renders a custom video player — with play/pause, a seekable progress bar,
time display, and a thumbnail poster — that streams the editorial from Cloudinary.
For deployment, the React frontend is built into static assets via Vite, suitable for any static
host or CDN, while the Express backend is deployed as a Node service with its environment
variables — database and Redis connection strings, JWT secret, and the Judge0, Gemini,
and Cloudinary credentials — supplied securely at runtime, with CORS configured to
permit only the deployed frontend origin.
CHAPTER 6

RESULTS AND DISCUSSION

6.1 Introduction
This chapter presents the outcomes of the project by demonstrating the working interface
of the EliteCode platform, summarising the testing performed, and discussing the extent to
which the stated objectives were achieved. The screens referencedespond
below corr
tothe
figures listed in the List of Figures; the placeholders marked “[Screenshot: …]” are to be
replaced with the captured images in the final printed report.

6.2 Description of Results (Screens)

The completed system delivers a fully functional, responsive interface across all modules.
The following screens, captured from the deployed application, demonstrate the key
features of the platform.
Authentication. The login screen presents a clean, centred form with inline
-sideclient
validation and a password
-visibility toggle. On successful authentication the session is
stored in the Redux store and the user is taken to the homepage. The corresponding
interfacesi shown in Fig. 12.

Fig. 12— Login Page

User Profile and Progress [Link] user has a profile page that displays personal
details and tracks progress across the problem set, including the overall solved count and a
difficulty-wise breakdown (Easy, Medium, Hard) together with the user’s global rank. This
is shown in Fig. 13.

Fig. 13— User Profile and Progress Dashboard

Problem Description Page. When a problem is opened, the left panel of the workspace
presents the full statement
— title, difficulty and topic tags, problem description, and
worked examples with input, output, and explanation
— along with aSolvedindicator once
the user has accepted a solution. A representative problem (“Two Sum”) is shown in Fig.
14.

Fig. 14— Problem Description Page (Two Sum)

Code Editor and [Link] right panel hosts the Monaco editor with a language
selector (here set to C++) and Editorial
the , Solutions, Submissions
, andCodetabs. The
editor provides syntax highlighting, line numbers, and a familiar, VS
-Code-like editing
experience, as shown in Fig. 15.

Fig. 15 — Code Editor with Monaco (C++ Solution)

Admin Panel. The administrative subsystem presents the content-management options —
Create Problem, Update Problem, Delete Problem, and Video Problem— through which
authorised staff manage the platform’s problem set and learning content, as sh
own in Fig.
16.
Fig. 16— Admin Panel

6.3 Testing and Validation

Software testing was conducted to verify that the system satisfies its specified
requirements and behaves correctly across valid, invalid, and boundary scenarios. The
testing combined unit testingof individual functions and components (such as the input
validator, the language
-id mapping, the verdict computation, and the-validation
form
schemas),integration testing of interactions across module boundaries (the flow from a
frontend action through the API, middleware, controller, and database, and the trips
round
to Judge0, Gemini, and Cloudinary),
system testing of the complete end
-to-end scenarios
of the use-case model, and
security testing of the access-control mechanisms.
Representative test cases and their outcomes are presented in Table 6.1; all listed cases
passed.
Table 6.1— Representative Test Cases and Results

TC ID Test Case Expected Result Result

TC- Register with valid data Account created; cookie set Pass
01
TC- Register with weak password Validation error; no account Pass
02
TC- Register with existing email Error: user already exists Pass
03
TC- Login with correct credentials Authenticated; cookie set Pass
04
TC- Login with wrong password Authentication error Pass
05
TC- Access protected route without 401 Unauthorized Pass 06 token
TC- Use token after logout 401 Unauthorized Pass
07 (blocklisted)
TC- List and filter problems Correctly filtered list Pass
08
TC- Run correct code (visible tests) All visible cases pass; output shown Pass 09
TC- Submit correct code (hidden Verdict accepted; runtime/memory Pass
10 tests) recorded
TC- Submit wrong code Verdict wrong; passed-count < total Pass
11
TC- Submit code with error Verdict error; message captured Pass
12
TC- Solved set updated on Problem added without duplication Pass 13
acceptance
TC- View submission history History with code, status, stats Pass
14
TC- Non-admin hits admin route Forbidden Pass
15
TC- Create problem with valid Problem saved Pass
16 references
TC- Create problem with failing Rejected; not saved Pass
17 reference
TC- Upload and stream solution Uploaded to Cloudinary; plays in player Pass 18
video
TC- Delete video Removed from Cloudinary and DB Pass
19
TC- AI tutor query Relevant, problem-scoped response Pass
20

All representative test cases passed, indicating that the implemented system meets its
functional and security requirements across the tested scenarios. Defects discovered
during development — chiefly around the correct interpretation of Judge0 status codes, the
polling-termination condition, and the propagation of credentialed cookies across origins
— were resolved and re-tested.

6.4 Discussion
The implemented system fulfils all of the objectives stated in Section 1.5. A secure
JWT-in-cookie sessions, role-based access control, and Redis-backed token revocation. A
clean, modular REST API was built and organised into five logical route groups, backed by a
well-validated four-collection data model. The Judge0 integration provides authentic
automated judging in three languages, with accurate verdicts and performance statistics,
and the reference-solution validation guarantees the integrity of every published problem.
The React frontend delivers a responsive, single-page experience built around a professional
code editor, and the AI tutor and video-editorial modules add genuine pedagogical value
tightly integrated into the problem-solving workflow.
The principal engineering lessons of the project concerned the careful handling of
asynchronous, externally dependent workflows — particularly the submit-and-poll cycle
against Judge0 — and the subtleties of credentialed cross-origin requests, which required
coordinated CORS and cookie configuration. The decision to externalise both code
execution and media storage proved especially valuable: it kept the application server
lightweight, sidestepped the considerable security risk of running untrusted code locally,
and yielded a design that scales horizontally. Measured against the comparison of Chapter
2, EliteCode successfully combines, in a single free and self-hostable application, a set of
capabilities that are otherwise scattered across — and often paywalled within — the
leading commercial platforms.
CHAPTER 7

FUTURE SCOPE
The architecture of EliteCode lends itself naturally to extension. While the present version
meets all of its objectives, the following enhancements are proposed for future work.
7.1 Contest Module. A time-boxed contest mode with live leaderboards, scoring, and a rating
system would support competitive practice and institutional events, drawing on the contest
model demonstrated by platforms such as Codeforces.
7.2 Expanded Language Support. Additional languages such as Python, C, and Go can be
integrated by extending the language-id mapping and the starter-code templates, broadening
the platform’s appeal.
7.3 Plagiarism and Similarity Detection. Automated comparison of submissions to detect
copied solutions would uphold academic integrity, an important consideration for institutional
deployment.
7.4 Discussion Forum and Editorial Comments. A community layer enabling learners to
discuss approaches and ask questions on each problem would complement the AI tutor
with peer learning.
7.5 Advanced Learning Analytics. Dashboards summarising a learner’s strengths and
weaknesses by topic and difficulty, with personalised problem recommendations, would
make the platform more adaptive and effective.
7.6 Company- and Topic-Wise Problem Sheets. Curated tracks aligned with the
interview patterns of specific companies and with curricular topics would help learners
prepare in a targeted manner.
7.7 Richer AI Capabilities. Step-wise hint laddering, automated complexity analysis of a
user’s own code, and personalised feedback would deepen the pedagogical value of the AI
assistant.
7.8 Native Mobile Application and Hardened Deployment. A companion mobile
application would broaden access, while containerisation, CI/CD pipelines, rate limiting,
centralised logging, and secrets management would harden the platform for
productiongrade operation. Adaptive-bitrate streaming and automatic transcoding of
editorial videos would further improve the learning experience across varied network
conditions.
The realisation of these enhancements would evolve EliteCode from a capable majorproject
platform into a production-grade learning ecosystem.

CHAPTER 8
CONCLUSION
The EliteCode project set out to design and build a secure, integrated, full-stack platform
for programming practice and technical-interview preparation, and it has achieved that
goal. The completed system unifies, within a single coherent application, the entire practice
workflow: browsing and filtering a curated problem catalogue; writing code in a
professional multi-language in-browser editor; running it against sample tests and
submitting it for automated judging against hidden tests; receiving an accurate verdict with
runtime and memory statistics; obtaining context-aware help from an AI tutor; learning
from streamed video editorials; and tracking one’s progress through a persistent
submission history and solved-problem set. Around this learner-facing experience, a
complete administrative subsystem allows authorised staff to manage problems, learning
content, and users, with a built-in integrity guarantee that prevents the publication of
inconsistent problems.
In building the system, the project demonstrated the practical application of a broad
spectrum of contemporary software-engineering concepts: the design of a RESTful,
serviceoriented backend; data modelling in a document database with validation,
references, and indexes; secure, token-based authentication and role-based authorisation
reinforced with a cache-based revocation mechanism; integration with multiple third-party
services for code execution, artificial intelligence, and media handling; asynchronous,
pollbased orchestration of long-running external tasks; and the construction of a responsive
singlepage user interface with disciplined client-side state management. The system was
validated through a structured, multi-level testing effort, and all representative test cases
passed.
The development process, structured as a sequence of well-defined phases, reinforced
sound engineering practices — incremental delivery, separation of concerns, and
continuous integration of each subsystem before the next was begun. The most valuable
lessons concerned the orchestration of asynchronous external services and the careful
handling of security across origins, both of which are central to modern web development.
EliteCode therefore stands both as a useful, working product for learners and as a
comprehensive demonstration of full-stack web-engineering competence appropriate to a final-
year major project. With the enhancements outlined in the future-scope chapter, it has clear
potential to evolve into a production-grade learning ecosystem serving a wider community of
students.

REFERENCES
[1] R. Elmasri and S. B. Navathe, Fundamentals of Database Systems, 7th ed. Pearson, 2016.
[2] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein, Introduction to Algorithms, 4th ed.
MIT Press, 2022.
[3] R. S. Pressman and B. R. Maxim, Software Engineering: A Practitioner’s Approach, 9th ed.
McGraw-Hill, 2020.
[4] Meta Open Source, “React — The library for web and native user interfaces.” [Online]. Available:
[Link]
[5] OpenJS Foundation, “[Link] Documentation.” [Online]. Available:
[Link]
[6] OpenJS Foundation, “Express — Fast, unopinionated, minimalist web framework for [Link].”
[Online]. Available: [Link]
[7] MongoDB Inc., “MongoDB Documentation.” [Online]. Available:
[Link]
[8] Automattic, “Mongoose ODM Documentation.” [Online]. Available:
[Link]
[9] Redux Team, “Redux Toolkit Documentation.” [Online]. Available: [Link]
[10] Tailwind Labs, “Tailwind CSS Documentation.” [Online]. Available:
[Link]
[11] Microsoft, “Monaco Editor — The code editor that powers VS Code.” [Online].
Available: [Link]
[12] H. Dosilovic and Judge0, “Judge0 — An open-source online code execution system.” [Online].
Available: [Link]
[13] Google, “Gemini API — Google AI for Developers.” [Online]. Available:
[Link]
[14] Cloudinary, “Cloudinary Documentation — Image and Video Management.” [Online]. Available:
[Link]
[15] Redis Ltd., “Redis Documentation.” [Online]. Available: [Link]
[16] Internet Engineering Task Force, “RFC 7519: JSON Web Token (JWT),” 2015. [Online].
Available: [Link]
[17] L. Richardson and S. Ruby, RESTful Web Services. O’Reilly Media, 2007.
[18] MDN Web Docs, “Web technology for developers,” Mozilla. [Online]. Available:
[Link]
[19] M. Fowler, Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
[20] OWASP Foundation, “OWASP Top Ten — Web Application Security Risks.” [Online].
Available: [Link]