All projects

No. 05Backend & Full-stack

Agent Gamification Platform

A gamification platform for sales agents — regional teams compete over a season with a live leaderboard, tiers, achievements, and redeemable offers.

  • Real-Time Systems
  • Gamification
  • Role-Based Access Control
  • Liveleaderboard over SignalR
  • 3roles: agent, admin, master

Tech stack

  • C#
  • .NET
  • ASP.NET Core
  • Entity Framework Core
  • SignalR
  • Angular
  • PostgreSQL

How it works

  1. 1Sale verified
  2. 2Score attributed to region/team
  3. 3Standings recomputed
  4. 4Live push to dashboard
  5. 5Tier/achievement check
01

Problem

A gamified platform to drive sales-agent engagement — agents are grouped into regional teams that compete over a season, with a live leaderboard, tiers, achievements, and redeemable offers.

02

Why it was difficult

Every verified sale needs to update a live leaderboard in real time and roll up into team standings without the leaderboard read path becoming a bottleneck as agents and sales grow. Access also needed three distinct roles — agent, admin, and master — with a two-level manager hierarchy layered on top.

03

Architecture

A .NET Web API backend (controllers, services, DTOs, an EF Core data layer) sits behind a SignalR hub that pushes typed real-time events — a sale, a tier upgrade, an updated leaderboard — to an Angular single-page app. One background service periodically recomputes live match scores from verified sales; another periodically snapshots the leaderboard for fast reads.

04

Technical approach

Leaderboard reads stay fast by maintaining running totals per agent and per team that update the moment a sale is verified, rather than aggregating from raw sales data on every page load. Role-based policies gate what each of the three user types can see and do.

05

Implementation

JWT-based auth with short-lived access tokens and longer-lived refresh tokens, plus password hashing and Swagger-documented endpoints throughout the API.

06

Challenges

SignalR client connections cannot always attach custom authorization headers, which conflicts with the header-based JWT scheme used everywhere else in the API.

07

Solution

The real-time hub accepts the JWT as a query-string parameter on its connection path specifically, while every other endpoint keeps standard header-based auth — a narrow, contained exception rather than weakening auth everywhere.

08

Evaluation

Not documented — no automated tests exist yet for this project.

09

Results

Not documented — ask Suraj for real engagement numbers if he wants them included.

10

Future improvements

The project currently runs against an in-memory database for local development, with a documented manual step to switch to a real production database as the clear next step.

Want something like this built?

Let’s talk