rahadulx0

~/projects/trikunja-tutor-matching

Trikunja

Intelligent Tutor Matching Platform

PROJECT_ID
PROJECT_01
TYPE
MARKETPLACE
STATUS
PRODUCTION
YEAR
2025
COMPLEXITY
O(k) per request, k = indexed shortlist
STACK
React · Django · Python · PostgreSQL · WebSockets · JWT

§01

Introduction

A full tutor-student marketplace with a weighted matching algorithm, role-based dashboards, real-time scheduling and an automated review loop.

  • › Weighted matching algorithm pairing students and tutors.
  • › Real-time scheduling and role-based dashboards.
  • › Automated review loop closing the booking lifecycle.

§02

Problem

Students and tutors relied on social media groups and word-of-mouth: matching was slow, unverified, and bookings happened entirely off-platform with no accountability. Simple filter-and-sort surfaced the same few high-rated tutors for every request, so students got slow responses from overbooked tutors and capable new tutors never got discovered.

§03

Constraints

Rank tutors by genuine fit (subject, availability overlap, location, rating), keep match queries fast as the pool grows, and give new tutors a fair chance without degrading match quality.

§04

Architecture

  1. CLIENT

    React SPA

    Role-based routing splits student and tutor experiences; JWT auth; optimistic UI on booking actions.

  2. API

    Django REST Framework

    Versioned REST endpoints with serializer-level validation, throttling, and permission classes per role.

  3. MATCHING

    Weighted scoring service

    Scores tutors on subject fit, availability overlap, rating, and distance; weights tuned against real booking outcomes.

  4. REALTIME

    WebSockets

    Pushes schedule changes and booking confirmations to both parties without polling.

  5. DATA

    PostgreSQL

    Composite indexes on (subject, area, rating) keep match queries under 100ms as the tutor pool grows.

§05

Implementation

A scoring service inside the Django API computes a weighted sum over normalized features. Availability overlap is precomputed into slots so scoring is a pure read. A small exploration bonus for low-history tutors solved cold-start at a measured, capped cost to average match score.

§06

Engineering challenges

Real-time scoring versus precomputation. Precomputing all pairs was wasteful at this scale, so candidates are scored per-request over an indexed shortlist.

§07

Results

−40%
TIME_TO_HIRE
100%
BOOKING_AUTOMATION
4.8★
SATISFACTION
<100ms
MATCH_QUERY

Cut average tutor time-to-hire by ~40%, automated 100% of the booking lifecycle, and reached a 4.8★ average satisfaction. New-tutor first-booking time improved without hurting repeat-booking rates.