01
the problem
Emergency command teams need one interface for incidents, alerts, resource coordination, permissions, and data arriving from distributed services.
cd ..~/projects/disaster-response-system
case study 04 / Distributed team system
Disaster Response System
A distributed academic platform organised across device, data, interaction, and platform-security subgroups, with a web command centre as its operational interface.
- status
- Completed
- ownership
- Team of 20
- stages
- 06
- stack
- 07
- Next.js
- TypeScript
- Socket.IO
- Kafka
- PostgreSQL
- Docker
- Vitest
Project overview
02
my contribution
Built the initial command-centre experience, including dashboard pages, the interactive incident map, resource and report workflows, authentication context, route guards, permissions, shared contracts, mock datasets, and focused unit tests.
03
key decision
Centralise typed roles and permission checks so navigation, protected routes, and actions use the same access model.
visual evidence pending
No repository screenshot is published for this project. A real application capture should replace this clearly marked placeholder.
04 / how it works
System flow
stage 01
Device & data services
stage 02
Kafka events
stage 03
Event bridge
stage 04
Command centre
stage 05
Incident map
stage 06
Role-aware actions
Oshadha-authored command-centre pages cover alerts, analytics, incoming reports, resources, and the initial incident-map experience.
Authentication context, reusable route guards, typed permissions, and role-aware navigation are supported by his commit history.
Unit tests cover permissions, filters, validation, and dashboard statistics.
Later Oshadha work improved unavailable-database behavior, alerts, audit access, and resource-plan interactions.
The current map receives Socket.IO updates, but that live integration was added later by a teammate and is not claimed as Oshadha’s contribution.
What is implemented and what is not
This was a 20-person academic project, so platform-wide features are team outcomes.
Some early Kafka and Socket layers in Oshadha’s contribution were documented stubs while other team members completed the live bridge.
The repository includes local demonstration credentials that must never be reused in production.
Keeping a broad operational UI testable and resilient while its upstream services and integration contracts were evolving across a large team.
Shared contracts and graceful failure states reduce integration friction in a distributed, multi-team system.