Geo Attendance System

Overview

Geo Attendance System is a full-stack geolocation attendance platform: users check in with GPS-backed validation, administrators review attendance through a React.js frontend, and a Spring Boot backend handles concurrent multi-user requests against MySQL.

John Prakash Balireddy contributed across the stack during his Mobiclo tenure — backend concurrency design, GPS spoof detection and location validation, Strategy and Repository patterns, and MySQL query optimization that reduced average query latency by roughly 35% under simulated load. This is a project case study, not a claim of sole platform ownership.

Business problem

Location-based attendance fails when the system cannot trust coordinates or keep up with concurrent usage:

1. Fake locations — users can spoof GPS; attendance records become unreliable without server-side validation.
2. Concurrent check-ins — many users checking in at once stress backend request handling and database reads/writes.
3. Slow reporting — admin views that aggregate attendance data degrade when queries are unindexed or poorly shaped.
4. Maintainable rules — attendance policies change; hard-coded validation paths become expensive to extend.

Solution

A three-tier platform separates concerns while keeping validation authoritative on the server:

• React.js frontend — attendance and administrative surfaces consuming REST APIs.
• Spring Boot backend — concurrent request handling, location validation, spoof detection, and attendance persistence.
• MySQL datastore — indexed queries tuned for reporting and check-in workloads under load.

Design patterns (Strategy for swappable validation rules, Repository for data access) keep location logic and persistence testable as requirements evolve.

Architecture

React.js client
      │ REST
      ▼
Spring Boot API
      ├── Location validation & GPS spoof detection (Strategy)
      ├── Attendance domain services
      └── Repository layer ──► MySQL (indexed queries)

| Concern | Approach | |---|---| | Concurrency | Spring Boot backend structured for multi-user simultaneous requests | | Location trust | GPS validation and spoof detection on the server, not client-only | | Extensibility | Strategy pattern for validation rules; Repository for data access | | Performance | Query optimization and indexing — ~35% lower average latency under simulated load | | Frontend | React.js for user and admin attendance flows |

Challenges

GPS spoofing and false positives

Pure client coordinates are untrustworthy. Validation must reject spoofed signals without blocking legitimate check-ins at edge cases — a balance handled in the backend validation layer, not by trusting the mobile browser alone.

Database latency under simulated load

Attendance reporting and check-in paths hit MySQL with patterns that degraded as data volume grew. Profiling queries and adding appropriate indexing produced a measurable ~35% reduction in average query latency under simulated load — the only published performance metric for this project.

Concurrent request safety

Multiple users checking in during the same window requires careful backend design so validation, persistence, and reads do not race into inconsistent records.

Technical decisions

1. Server-side location authority — GPS spoof detection and validation run in Spring Boot; the client submits coordinates, the server decides.
2. Strategy pattern for validation — attendance and location rules stay swappable without rewriting core services.
3. Repository pattern for MySQL access — isolates query shapes so indexing work targets known access paths.
4. Index-driven query optimization — measured ~35% average latency improvement under simulated load; no other metrics are claimed here.
5. Full-stack ownership within intern scope — John contributed backend, frontend, and database work as part of Mobiclo delivery, not as sole architect of every policy decision.

Responsibilities

• Built full-stack geolocation attendance flows with Spring Boot and React.js
• Implemented GPS spoof detection and location validation on the backend
• Applied Strategy and Repository design patterns for maintainable validation and data access
• Optimized MySQL queries and indexing for concurrent multi-user workloads

Gallery

Text-only descriptions of core surfaces:

1. Geolocation check-in — GPS-backed attendance capture validated before persistence.
2. Spoof detection — Backend layer protecting attendance integrity from suspicious location signals.
3. Admin and reporting views — React.js UI over optimized MySQL-backed queries.

Technologies

Backend: Java, Spring Boot, REST APIs, Strategy and Repository patterns, GPS validation and spoof detection.

Frontend: React.js.

Data: MySQL with indexing and query optimization.

Process: Full SDLC contribution from design through deployment.

Lessons learned

• Never trust client GPS alone — spoof detection belongs in server validation, with patterns that allow rule changes.
• Measure database work — simulated load exposed latency that unit tests missed; indexing delivered a real ~35% improvement.
• Patterns pay off early — Strategy and Repository kept location rules and queries maintainable as attendance logic grew.

Future improvements

• Expand automated load tests tied to the indexing strategy so regressions are caught in CI.
• Harden edge-case handling for location validation as new spoof techniques appear.
• Optional mobile-native client integration — related mobile GPS work appears in projects such as OnHob.