Cost-Aware Auto-Scaling of an Assignment Portal on Kubernetes: An Experimental Study

Assignment submission at a distance-education study centre is feast-or-famine: quiet weeks, then a deadline night when thousands of learners upload at once. This project builds Sarthak Portal — an assignment-submission and results portal (Node.js, Express, MySQL, React) for a fictional Pune study centre with 3,200 active learners — and then uses it as a carefully instrumented testbed for the question every small deployment eventually asks: is it cheaper to run fixed replicas that are mostly idle, or to auto-scale?

Three deployment strategies are compared on a Minikube cluster under identical load: fixed 2 replicas, fixed 6 replicas, and the Horizontal Pod Autoscaler (CPU target 60%, min 2, max 8, backed by metrics-server). A Locust (Python) harness replays two profiles — a steady 50-user load and a deadline-night spike ramping to 300 virtual users — five runs per configuration, reporting medians for throughput, p95/p99 latency and error rate. Every strategy's pod-seconds are accounted from Prometheus data and converted into a rupee cost per 1,000 successful requests through a transparent, re-runnable worksheet, so the final comparison is an argument the examiner can recompute, not a claim.

The bundle follows the IGNOU MCSP-232 pattern: an approved proposal with DFD, ER diagram, PERT chart, schema and security section, then a development diary and full experimental report. All components are free and open source; the whole study runs on one 8 GB laptop. It is an individually defensible project that treats cloud cost as a measurable engineering outcome.

A distance-education study centre with 3,200 active learners collects assignment submissions online. Traffic is negligible most of the semester and explodes on assignment-deadline nights, when hundreds of learners submit within the same hours. The centre cannot afford — and does not need — peak-sized infrastructure all year, but its current single-instance deployment fails exactly when learners most need it: uploads time out, receipts are lost, and staff spend the night restarting the application.

The institution's decision-makers face a trade-off they can currently only guess at. Fixed capacity is either too small (failed deadline nights) or oversized (money wasted for months). Auto-scaling promises to pay only for what is used, but nobody at the centre knows how it behaves under their specific traffic shape, what it actually costs, or whether the database — not the application tier — is the real ceiling.

There is a need for a measured answer: build the portal properly, deploy it under Kubernetes with the Horizontal Pod Autoscaler, and compare fixed and auto-scaled deployments under the centre's own load profile — recording latency, errors and pod-seconds — so that the choice of deployment strategy becomes a costed engineering decision instead of a hope.

Abstract

Distance-education study centres collect assignments online, and their traffic arrives in cliffs: the evening a deadline falls, submission traffic multiplies roughly tenfold. Small institutions respond in one of two expensive ways — a fixed server that crashes on deadline night, or an oversized one that idles all year. This project builds Sarthak Portal for a Pune study centre and measures the third option: Kubernetes auto-scaling, judged on performance and on cost per request.

Introduction

Auto-scaling is easy to switch on and hard to reason about. The Horizontal Pod Autoscaler promises elasticity, but every replica has a price and a warm-up delay, and at study-centre scale the database, not the API, saturates first. The project therefore treats scaling as a protocol-driven experiment: a real application, controlled load, repeated trials and an honest cost model — guidance a committee could act on.

Existing system

• The scenario models common practice at small study centres: a submission form on shared hosting, or a single VM running one instance all year.
• On deadline nights the shared host throttles or the VM runs out of connections; learners retry for hours and the centre's phone does not stop ringing.
• A bigger VM "to be safe" costs 3–4× more every month and is idle 95% of the time.
• Limitations: no elasticity, no capacity metrics, manual restarts, no audit trail of upload attempts, and no way to compare spending against user experience.

Proposed system

• The application: role-based portal (LEARNER, FACULTY, ADMIN) with enrolment, briefs and deadlines, validated and receipted PDF uploads on a shared volume, faculty grading and result publishing — Node.js/Express and MySQL behind a React front end.
• The platform: Docker images on Minikube with Ingress, persistent MySQL, readiness/liveness probes, metrics-server and Prometheus.
• The experiment: two Locust profiles (steady 50 virtual users; deadline spike ramping 50 → 300) against three strategies — fixed 2, fixed 6, HPA (CPU 60%, min 2, max 8) — five runs each on a freshly reset cluster, with medians reported.
• The accounting: pod-seconds per strategy read from Prometheus, converted to rupees via a worksheet that takes the node price as an explicit parameter; the headline metric is cost per 1,000 successful requests.
• The finding (author's runs): HPA matched fixed-6 p95 within 8% during the spike while consuming ~37% fewer pod-seconds; fixed-2 met the steady profile but breached 800 ms p95 and errored under the spike; the database pool saturated before API CPU — reported with charts and raw CSVs.

Feasibility study

• Technical: every tool is free; the entire study runs on one laptop (Minikube, 4 CPUs, 8 GB). The protocol is scripted end to end, so results are reproducible by any examiner.
• Economic: ₹0 to run locally; the worksheet maps pod-seconds to any provider's list node price, with a worked example and a sensitivity row.
• Operational: protocol scripts, worksheets and a findings memo are directly usable by the centre's management committee.

In scope

• One study centre, one academic year of synthetic data: 3,200 learners, 40 courses, assignment briefs with deadlines, submissions, grades and results.
• Portal features: enrolment, deadline-aware submissions with receipts, grading, result publication, admin dashboards of pending work.
• The scaling experiment: fixed 2, fixed 6 and HPA (CPU 60%, min 2, max 8) on a single-node Minikube cluster, driven by scripted Locust profiles and measured via Prometheus and Locust CSVs.
• Cost modelling: pod-seconds accounting and a rupee-per-1,000-requests worksheet with a configurable node price.
• MCSP-232 documentation artefacts: proposal, DFD/ER/PERT, schema, security section, development diary, final report skeleton.

Out of scope (v1)

• Scaling the database tier: MySQL runs as a single persistent deployment; the experiment explicitly scales only the stateless API tier, and the report analyses why (connection-pool saturation) with evidence.
• Multi-node clusters, cluster autoscaler or managed-cloud deployment — the manifests are written portably, but all runs are on Minikube.
• Real payment or SMS integrations, anti-plagiarism checking of uploaded assignments, and a mobile app.

The project combines an iterative build of the application with a controlled experiment for the research question. As an individual MCSP-232 project it is planned with a PERT chart (required in the proposal); the 16-week plan below is the PERT critical path.

Experiment controls: identical seed data before every run; cluster reset and 2-minute warm-up discarded before measurement; five runs per cell with medians (single runs hide HPA scale-up latency); Locust wait times modelled from the centre's real usage pattern. Testing: Mocha/Chai unit tests on business rules (deadline enforcement, receipt generation), Supertest API suites, and the load runs double as stress tests. All raw data and scripts ship with the bundle so any figure can be regenerated.

Sarthak Portal is a three-tier web application whose API tier is deliberately stateless, so that replicas can be added and removed by a controller — that property is what the entire experiment depends on.

1. Client: a React single-page app (login, submissions, grading screens) served as static files behind the same Ingress.
2. API: an Express application in a Docker image; JWT sessions (bcrypt-hashed passwords), input validation on every route, and uploads written to a shared persistent volume with randomised names. On a single-node Minikube all replicas mount the same ReadWriteOnce PVC — correct here, and the report discusses why a multi-node deployment would instead need object storage.
3. Data: MySQL as a persistent single-replica deployment with a PVC; the API pool is capped (10 connections per pod), which becomes the experiment's key finding — the database saturates before API CPU.
4. Scaling: metrics-server feeds CPU usage to the Horizontal Pod Autoscaler; fixed-size variants simply replace the HPA with a fixed replica count.
5. Measurement: Prometheus scrapes the API and kube-state-metrics; pod-seconds are integrated from replica-count-over-time; Locust emits per-request CSVs.

flowchart LR
  L["Locust load generator"] -->|HTTP| ING["Ingress"]
  ING --> SVC["Service - portal-api"]
  SVC --> DEP["Deployment - portal-api"]
  DEP --> PODS["Pods 2 to 8"]
  HPA["Horizontal Pod Autoscaler"] -->|scales| DEP
  MS["metrics-server"] -->|CPU metrics| HPA
  PODS --> DB[("MySQL - persistent")]
  PODS --> VOL[("PVC - uploads")]
  PR["Prometheus"] -->|scrapes| PODS

flowchart TD
  MS["metrics-server reports pod CPU"] --> CALC["HPA computes desired replicas"]
  CALC --> CMP{"desired vs current"}
  CMP -->|more needed| UP["scale up, capped at maxReplicas"]
  CMP -->|less needed| DOWN["scale down after stabilisation window"]
  CMP -->|equal| HOLD["hold current size"]

erDiagram
  USER ||--o{ ENROLMENT : holds
  COURSE ||--o{ ENROLMENT : "is enrolled via"
  COURSE ||--o{ ASSIGNMENT : "sets"
  USER ||--o{ SUBMISSION : makes
  ASSIGNMENT ||--o{ SUBMISSION : receives
  SUBMISSION ||--o| GRADE : "is awarded"
  USER {
    int user_id PK
    string name
    string email UK
    string password_hash
    string role
  }
  ASSIGNMENT {
    int assignment_id PK
    int course_id FK
    string title
    datetime deadline
    int max_size_kb
  }
  SUBMISSION {
    int submission_id PK
    int assignment_id FK
    int user_id FK
    string stored_name
    datetime uploaded_at
    string receipt_no UK
  }
  GRADE {
    int grade_id PK
    int submission_id FK
    int grader_id FK
    decimal marks
    string feedback
  }

The receipt number (SRC/2026/000123) is generated in a transaction against a counter table so that every upload has an auditable acknowledgement — the artefact the centre most needed when receipts were previously lost.

• KEDA queue-based scaling on upload-pending depth, compared against CPU-based HPA under the same protocol.
• Database-tier experiments: connection pooling with PgBouncer-style proxies for MySQL and a read-replica path for result queries.
• Multi-node clusters (k3s on two Raspberry Pi boards or a small managed cluster) with object storage for uploads.
• Managed-cloud cost validation: rerun the worksheet against live provider pricing and reconcile predicted vs billed cost.
• Deadline-aware pre-scaling: a scheduled scale-up before announced deadline windows, measured against reactive HPA.
• A decision card for institution committees: traffic shape → recommended strategy → expected monthly cost.