# PRD: Mitra online status And Pairing Logic

# Overview

**Goal:** To build mitra online status and pairing logic between Mitra and Customer

**Success looks like:** Mitra can set status to online. System can pair Mitra and Customer for chat acceptance request. System can determine how many Customer connected with Mitra

## Background
- We need our Mitra do determine whether they are able to receive chat request or not through Online or Offline status
- System can keep track which Mitra is online and how many active session they currently handle
- System can have logic on how to pair Customer with Mitra. Either it is round robin or based round robin with weight
- Control center can determine how many Customer can Mitra handle globally
- When needed, control center user can re route request to other Mitra


# Functional Requirement

## Mitra online status
Mitra online status functional requirement:
1. Mitra can set their status online of offline from mobile app
2. Mitra with status online will be visible by system for pairing process
3. Online status will have their log. showing when they were online and when they were offline. 
4. Be noted, that Mitra can be online and offline multiple times a day

## Customer Chat Request
Customer chat request on this phase will be just simple pairing, with lead to pairing process only. the real process will be on next phase.

Functional requirement:
1. Customer click CTA "Mulai Curhat"
2. System will look for mitra using Pairing method defined in different section
3. While system look for mitra and waiting for Mitra's confirmation, customer app will shows "Searching for Bestie" page
4. When mitra confirm chat request, customer app will briefly shows "Bestie ditemukan, menghubungkan kamu ke Bestie"
5. Customer will then showed a screen that they had paired with bestie named "bestie name"

## Mitra Pairing Backend
Pairing is a process in backend for system to look for Mitra's availability. Functional requirement:
1. Control Center user can config how many Customer, Mitra can handle
2. System will keep track of Mitra and Customer active chat session
3. When pairing request is coming, system will look for Mitra that is online and has active chat session less than maximum Mitra can handle
4. System then blast to all available Mitra that there is incoming chat Request
5. When one of the Mitra accept, system will pair them and start the session
6. Pairing flow will be:
    1. Customer request for pairing
    2. System blast to all available mitra
    3. One of the Mitra will accept the Chat Request
    4. Cutomer will receive notification that Bestie (Mitra {display name}) is accepting the request, it will trigger payment flow. Payment flow will be skipped on this phase
    5. Once payment confirmed (which is skipped), System will show session start screen


## Control Center Chat Management
Control center will have following functionality:
1. Control Center user can set how many Customer can be handled by a Mitra
2. Upon Customer count per Mitra changes, system will only affect new incoming chat request, *AND NOT* the existing one
3. When needed, Control Center user can reroute (re assign) existing Chat Session to other Mitra. It can be rerouted both during mid session or when the session is waiting for payment. Payment is on next phase, so be prepare for it
4. Control Center user can see how many active chat, how many active Mitra, how many active request and how many Customer per Mitra

## Tech Stack
Use existing tech stack, and extend if needed, such as valkey for pubsub. 