Bhuvan M. Acharya
The Archive
All work
Case study/2026 – 27/active

Atrang

Full-stack management system for Atrang, IIIT Tiruchirappalli's technical fest — with a Three.js 3D world as the front door.

Role

Team of 4 — DBMS Lab (24CS305 / CS3106) — my part:

Stack

Next.js · Three.js / React Three Fiber · Java 21 · Spring Boot 3.3.4 · PostgreSQL · Flyway V1–V9 · Docker

Source

GitHub

Live demo

Project demo

Problem

A technical fest is a firehose of events, schedules, venues and people — usually managed through a tangle of Google Forms and a pinned message. Participants can't see what's happening; organizers can't manage what they can't see.

Motivation

Atrang is the institute's technical fest, and it deserved infrastructure as interesting as the events themselves — the fest treated as a world, not a form list. Built as the extended full-stack DBMS architecture project for the Database Management Systems Laboratory (24CS305 / CS3106).

Architecture

Public showcase and the explorable fest worldNEXT.JS · THREE.JS / R3F 3D WORLDAnyone can browse the fest/EVENTS — PUBLICCommand center behind session auth/ADMIN — PROTECTEDSession-cookie authenticationHTTP + JSON + SAMESITE HTTPONLY SESSION COOKIE(ATRANG_SESSION_ID)REST controllers, DTOs, JPA layers, security testsSPRING BOOT 3.3.4 · JAVA 21SPRING SECURITY + BCRYPTRelational core with NOT NULL, UNIQUE, CHECK constraintsPOSTGRESQL — 3NF, 5 TABLESVersioned migrations, analytical views, audit triggerFLYWAY V1–V9 · VIEWS · TRIGGERS
Architecture — atrang

Technical decisions

  • A 3D world as navigation — the fest rendered as an explorable space (Three.js / React Three Fiber); the public showcase lives at /events.
  • Session-cookie authentication: same-site HttpOnly session cookie (ATRANG_SESSION_ID), passwords stored as BCrypt hashes (cost 10) — never plaintext.
  • Flyway migrations V1–V9: five 3NF relational tables with NOT NULL / UNIQUE / CHECK constraints, foreign keys with explicit delete rules.
  • Database doing real work: analytical views (v_event_details, v_category_metrics), an automated audit trigger (trg_events_audit_log), and a stored function (fn_get_fest_stats()) for system-wide metrics in one query.

Team & ownership

A four-person team, built on contributor branches integrated through main:

  • Yogesh — database architect: Flyway migrations (V1–V9), the DDL schema, views and functions, the DBMS project report.
  • Shreyash — backend engineer: Java 21, Spring Boot 3.3.4, Spring Security, REST APIs and DTOs, JPA entities, unit and security tests.
  • Madhav — frontend engineer: the Next.js admin panel (/admin pages), auth context, API client.
  • Me — .

Personal contribution

Team of 4 — my part: .

Outcome

In development — five 3NF tables with analytical views, an automated audit trigger and a stored function behind the Spring Boot API. The project demo is deployed and running.

Lessons learned

An event system is mostly an approval workflow wearing a party hat. And integration — making four people's branches into one verified build — is its own engineering discipline.

Outcome

In development — five 3NF tables with analytical views, audit triggers and a stored function behind the Spring Boot API; the project demo is deployed.

Project demo Repository

Next case study

OFFLINE