HomeLLMAgentConsortium ChainDigital humanWebsite buildAPPIntellectual PropertyCase studiesArticlesTech stack在线演示 Technical consulting

Home / Case studies / A municipal safety education platform

Education / website + course platform

City Safety Education Platform

A unified city-wide safety education entry point integrating learning, assessment and records.

Background

Safety education for the city's primary and secondary schools is scattered across individual schools: resources are inconsistent and learning records do not interoperate.

The education authority needs one entry point to push out courses and see how each school implements them.

School network conditions also have to be taken into account — you cannot require every school to upgrade its bandwidth.

Solution

Delivered a municipal safety education platform with course learning, online assessment, learning records and statistical reports.

Courses are classified by school stage and theme; schools can choose compulsory and elective courses.

Learning records are aggregated automatically into a personal file and traceable across academic years.

Statistical reports drill down by district, school and grade, and the responsible authority can export them directly.

Technical composition

The table below lists this project's technical elements so clients can verify them independently.

Tech stack

FrontendNext.js server-side rendering
ModuleCourse learning · Online assessment · Learning records · Statistical reports
PerformanceServer-side rendering, usable on weak networks
StatisticsMulti-dimensional drill-down by district/county, school and grade

Outcomes

  • The city now has a single entry point for safety education, and resources are no longer scattered.
  • Study and assessment records are traceable across academic years without gaps.
  • The regulator can view implementation rates by dimension, so management has evidence.
  • Server-side rendering means schools can use it without upgrading bandwidth.

Capabilities Used

Discuss a similar scenario

01 / Constraints

The constraints the project was built under

Project stories without constraints are fiction. This section sets out four constraints: time, site, staffing and compliance.

These constraints directly shape the solution; every problem under 'Key challenges' below is forced out by one of them.

Four kinds of constraint

ScopeOne unified entry point for all city schools, from urban districts to townships.
AccountStudent and teacher accounts must integrate with the existing student records system — no duplicate accounts.
UseUsage peaks concentrate in the start of term and Safety Month, when instantaneous concurrency is dozens of times the normal level.
RetentionLearning records must persist across academic years, not reset annually.
02 / Key challenges

Where It Actually Gets Stuck

It is not “we worked hard”; it is “what the problem looked like, how we solved it, and what it cost”.

How accounts integrate with the student records system

With separate accounts, transfers, graduations and new intakes would all need manual maintenance — hundreds of schools are simply unmanageable.
How we solved it: the student records system became the master data source — daily incremental sync of enrolment changes, with the platform only mapping, never editing. Transfers follow automatically, graduates are archived and new students get accounts. The cost is dealing with dirty data in the student records system (missing IDs, duplicate names, blank classes).

Concurrency collapses at the start of term

In the first week of the first term, the platform stalled noticeably during peak login periods.
How we solved it: three layers — push all static assets to local storage and CDN; cache sign-in and query endpoints to relieve the database; move non-critical statistical queries to offline batch jobs. The next year ran smoothly at the same peak.

How records are kept across school years

The original design archived by academic year, but the department in charge wants a three-year growth track, and once archived the history is no longer accessible.
How we solved it: organised data by person rather than by school year — one master record per student, with each year's learning data attached beneath it. Archiving only sets a flag, never deletes, and records expand on demand when queried.
03 / Reusable elements

What other projects can borrow directly

This section is for peers. If you are doing something similar, these points will save you a few detours.

Student records system as the master data source

Education platforms should not build their own user system; integrating with student records is the only sustainable approach.

Provision resources ahead of peaks

Traffic to education platforms is pulsed; sizing for average concurrency is guaranteed to collapse.

Organise data by person, not by school year

Cross-year queries are a very common requirement, so the data model must be designed around the person from the start.

04 / Retrospective

If we did it again

Talking only about successes is unconvincing. This section covers what we got wrong or did too late.

Doing it again, we would add data-quality validation in version one. The student records system contains a lot of non-standard data, which surfaced as assorted anomalies in the front end after sync — the cleansing effort was three times what we expected.

We underestimated peak load. We sized concurrency as a share of enrolled students, but at the start of term everyone logs in at once, so the ratio was far higher than expected.

Mobile adaptation came late. The design was PC-first, but many students actually use phones, so a mobile version was added later.

← All case studies Back to home