Dockerised Coaching-Centre Fee & Attendance App with a Backup/DR Study (Python/Flask + MySQL)

Dockerised Coaching-Centre Fee & Attendance App is a small but complete web application built for a typical Indian tuition/coaching centre (about 300–400 students across morning and evening batches), and it is deployed the way modern small services are deployed: as Docker containers with a written, tested backup and restore (DR) runbook.

The business side of the app is deliberately beginner-sized. The owner/admin manages batches, students and fee instalments and issues receipts; teachers mark batch attendance in a few taps; the dashboard shows today's collections, absentees and upcoming instalments. Security is a first-class section (hashed passwords, parameterised SQL, session handling) rather than an afterthought.

The cloud/operations side is what makes this project different from an ordinary CRUD project. The entire stack — Flask application, MySQL database and an Nginx reverse proxy — runs from one docker-compose.yml, so the system can be rebuilt on any machine in minutes. A backup service runs mysqldump on a schedule, and the project documents and actually executes a disaster-recovery drill: delete the database volume, rebuild the containers, restore from the latest dump and measure the recovery time against the stated RTO. A short study compares two deployment options (a local mini-PC versus a free-tier cloud VM) on cost, restart behaviour and backup safety.

For an IGNOU BCSP-064 project this gives you a level-2 DFD, a security section and a measured experiment — without needing any paid cloud account.

Coaching centres collect term fees in instalments and take attendance twice daily, yet most still track this on paper and a single spreadsheet. The spreadsheet has no backup, sits on one laptop shared with the family, and nobody knows how to rebuild the records if the disk dies. Requests like "which students have unpaid instalments?" or "was Rahul's second instalment paid in June?" take manual searching, and disputes are settled from memory. Attendance compilation for fee-blocking defaulters is done by hand every month.

The organisation needs a small, secure web application that records students, batches, instalments and attendance in one database, produces receipts and defaulter lists instantly — and, just as importantly, an operations plan that makes the data survive failure: containerised deployment that can be rebuilt anywhere, scheduled backups, and a disaster-recovery procedure that has actually been rehearsed and timed rather than merely written about.

Abstract

Small coaching centres in India run almost entirely on paper and spreadsheets: fee instalments are tracked in a diary, attendance in a register, and receipts are handwritten. Worse, whatever digital records do exist usually live on one office laptop with no backup — a disk failure can wipe out months of fee history. This project builds a small fee and attendance web application for such a centre and treats it as a real deployment problem: the application runs in Docker containers, backups run automatically, and a documented disaster-recovery procedure is tested end to end, with recovery time actually measured.

Introduction

The fictional organisation for this study, Ashirwad Career Academy, teaches about 350 school students in four batches. The owner collects fees in three instalments per term, teachers take attendance twice daily, and records live in a paper register plus an Excel sheet on a single laptop. The project replaces this with a Flask + MySQL web application with two roles, and then packages and operates it like a small production service.

Existing System

• Fee instalments and dues are written in a diary; receipts are handwritten carbon copies.
• Attendance is on paper; compiling a monthly defaulters list takes an evening of manual counting.
• The Excel sheet exists on one laptop only; there is no backup schedule, no off-device copy and no documented recovery procedure.
• Limitations: single point of failure, no audit trail, disputes about paid instalments, and heavy manual work at term boundaries.

Proposed System

• A web application with batches, students, instalment plans, receipt recording and batch attendance, on a normalised MySQL schema.
• Containerised deployment: the Flask app, MySQL and Nginx run as three containers defined in one Docker Compose file, so the whole system is reproducible from a clean machine.
• Automated backups: a scheduled mysqldump job writes timestamped dumps to a mounted backup volume, with retention of the last 14 dumps.
• Tested DR runbook: a written procedure with a stated RPO (24 hours — one backup cycle) and RTO (30 minutes), executed once as a drill: destroy the database container and volume, rebuild, restore, verify counts and record the measured recovery time.
• Deployment study: a short comparison of hosting the stack on a spare mini-PC versus a free-tier cloud VM (cost, restart behaviour after power cuts, backup exposure), with screenshots and measurements.

Feasibility Study

• Technical: Python/Flask and MySQL are covered in the IGNOU BCA curriculum; Docker Desktop runs on the student's own laptop, so nothing depends on a paid or internet-only service. Every command used is documented in the report.
• Economic: the entire stack runs on free software. The cloud-VM option in the study uses a free-tier machine; the mini-PC option reuses existing hardware. Total cost ₹0.
• Operational: two simple roles (Admin, Teacher) with a form-based interface; the owner needs one 30-minute walkthrough, teachers need none. The backup/restore runbook is a one-page checklist the office can follow unaided.

In scope

• One coaching centre, four batches, up to ~500 students; two roles (Admin, Teacher).
• Student and guardian registry (contact numbers only — the design stores no government ID numbers), batch and subject mapping, instalment plans per student.
• Receipt recording (cash/UPI reference number), dues and defaulter reports, printable receipt view.
• Batch-wise attendance marking with a monthly summary; attendance-linked defaulters view.
• Docker Compose deployment of app + MySQL + Nginx, scheduled backups, DR runbook, one executed restore drill with measurements.
• Comparison study of two deployment options with a cost/reliability table.

Out of scope (v1)

• Online payment gateway integration (payments are recorded with a reference number).
• SMS/WhatsApp notifications to guardians.
• Multi-branch or multi-tenant support; mobile apps (the web UI is responsive instead).
• Production-grade monitoring stacks (Prometheus/Grafana) — a simple health endpoint and log review are used instead.

The project follows the incremental SDLC model, chosen because a working system must exist early and each operations experiment (containerisation, backup, restore drill) needs the previous increment to be stable. Every increment was analysed, designed, built and tested before the next began, which suits an individual project stretched across the BCSP-064 semester.

Testing approach: unit tests for fee arithmetic (instalment totals, dues), transaction handling and authentication helpers using pytest; black-box test cases for every screen recorded in a test-case table; the DR drill itself is a repeatable test with an expected outcome (record counts match, measured recovery ≤ 30 minutes).

The system uses a three-tier architecture packaged as three containers. The presentation tier is server-rendered Jinja2 templates with minimal vanilla JavaScript. The application tier is a Flask app exposing page routes and a JSON health endpoint; all business rules (instalment calculations, dues, role checks) live in a service layer. The data tier is MySQL 8 with the database files on a named Docker volume. Nginx terminates HTTP traffic in front of the app and serves static files, so the Flask dev server is never exposed.

flowchart TD
  B[Browser: Admin / Teacher] -->|HTTP| N[Nginx reverse proxy]
  N --> A[Flask app container]
  A --> S[Service layer and role checks]
  S --> P[Parameterised SQL]
  P --> DB[(MySQL 8 container)]
  DB --- V[(mysql-data volume)]
  CR[cron backup job container] -->|mysqldump| DB
  CR --- BV[(backups volume)]
  A --> H[/health endpoint/]

ER diagram

erDiagram
  USER ||--o{ RECEIPT : records
  BATCH ||--o{ STUDENT : contains
  STUDENT ||--o{ INSTALMENT : "is billed"
  INSTALMENT ||--o{ PAYMENT : "is settled by"
  BATCH ||--o{ SESSION : schedules
  SESSION ||--o{ ATTENDANCE : "is marked in"
  STUDENT ||--o{ ATTENDANCE : belongs
  USER ||--o{ BACKUP_LOG : triggers

  USER {
    int id PK
    string username UK
    string passwordHash
    string role
  }
  BATCH {
    int id PK
    string name
    string subject
    string timing
  }
  STUDENT {
    int id PK
    int batchId FK
    string name
    string guardianPhone
    string status
  }
  INSTALMENT {
    int id PK
    int studentId FK
    decimal amount
    date dueDate
    string status
  }
  PAYMENT {
    int id PK
    int instalmentId FK
    decimal amount
    string reference
    date paidOn
  }
  SESSION {
    int id PK
    int batchId FK
    date sessionDate
  }
  ATTENDANCE {
    int id PK
    int sessionId FK
    int studentId FK
    string status
  }
  BACKUP_LOG {
    int id PK
    datetime startedAt
    string fileName
    string result
  }

DFD — Level 0 (context diagram)

flowchart LR
  AD([Admin]) -- students, plans, payments --> SYS((Coaching Centre<br/>Fee and Attendance System))
  SYS -- dues, defaulter and collection reports --> AD
  T([Teacher]) -- attendance --> SYS
  SYS -- batch attendance summary --> T
  BK([Backup job]) -- scheduled dump request --> SYS
  SYS -- dump files --> BK

DFD — Level 1

flowchart TD
  AD([Admin]) --> P1[1.0 Authenticate]
  T([Teacher]) --> P1
  P1 <--> D1[(D1 Users)]
  AD --> P2[2.0 Manage students and plans]
  P2 <--> D2[(D2 Students and Batches)]
  T --> P3[3.0 Mark attendance]
  P3 <--> D3[(D3 Sessions and Attendance)]
  AD --> P4[4.0 Record fees]
  P4 <--> D4[(D4 Instalments and Payments)]
  AD --> P5[5.0 Generate reports]
  P5 <--> D4
  P5 <--> D3
  P6[6.0 Run scheduled backup] --> D5[(D5 Backup Log)]
  P6 -- dump file --> BV[(Backup volume)]

DFD — Level 2 (process 4.0 exploded — required by the BCSP-064 synopsis format)

flowchart TD
  AD([Admin]) --> P41[4.1 Validate instalment request]
  P41 --> P42[4.2 Check dues status]
  P42 <--> D4[(D4 Instalments)]
  P42 --> P43{Fully paid?}
  P43 -->|yes| P44[4.4 Reject and show message]
  P43 -->|no| P45[4.3 Record payment and update status]
  P45 --> D4
  P45 --> D6[(D6 Receipts)]
  P45 -- receipt data --> R([Receipt view])

Every external entity, store and flow shown here appears in the report in the same order the viva asks for them: context first, then the level-1 decomposition, then the level-2 explosion of the fee-recording process.

• Automated restore verification: a monthly job that restores the latest dump into a scratch database and reports row-count mismatches, so backups are proven good, not assumed good.
• Off-site backup copy: push an encrypted dump to cloud object storage (free tier) so a laptop theft does not destroy both original and backup.
• Guardian notifications over SMS/WhatsApp for absence and upcoming instalments.
• Online payments via UPI deep links with automatic receipt reconciliation.
• Prometheus + Grafana monitoring of the health endpoint and backup job, with alerting on a missed backup window.
• Multi-branch support and a role for franchise owners with consolidated dashboards.