# Production scale, reliability, and permissions

## Request flow

Telegram → HTTPS webhook → SQLite durable inbox → update processor → ticket database → delivery outbox → manager/senior inboxes.

Termux mode instead uses Telegram long polling, but both modes use the same ticket and routing logic. Only one mode should be active for a given bot token.

## Role access

- Public user: `/start`, `/help` only in the Telegram command menu.
- Manager: ticket list, own duty switch, ticket reply/close/escalate, senior contact.
- Head manager: wider support oversight and escalations; no manager-management commands.
- System admin: manager roster/shift/role configuration, all-ticket views, settings, audit and welcome-video controls.
- Server-side permission checks are authoritative. Hiding commands is a convenience, not a security boundary by itself.

## Shift/routing rules

- An enabled manager is eligible for new assignment only when marked on duty and within their configured daily start/duration window.
- Duration is configurable from 1 to 24 hours; windows can cross midnight.
- New normal tickets are assigned to the eligible manager with the fewest open tickets, then round-robin tie-breaks.
- After assignment, normal messages remain with the assigned person unless staff escalation or authorized reassignment changes the ticket.
- Urgent keywords mark a ticket high priority and direct it to the configured senior support recipients; there is no customer-facing emergency button.
- If no manager is available, new tickets go to configured senior recipients. If none can be reached, delivery stays in the outbox and retries. Telegram bots cannot reliably inspect a user's real online status; receipt/delivery failures and configured duty are used instead.

## Durable data

- Incoming user messages are recorded in ticket metadata before sending the success acknowledgement; delivery jobs are persisted with unique dedupe keys.
- cPanel webhook updates are stored before returning HTTP 200. Once processed, the raw update JSON is cleared; ticket transcripts hold their own limited metadata and text.
- Message transcripts and audits may include private customer information. Restrict app/database access, protect backups, choose an appropriate retention period, and inform users that support messages are recorded.
- Telegram update retention is finite (not guaranteed beyond 24 hours); offline backlog is not unlimited.

## What is still required for millions of users

This package is not benchmarked for millions of simultaneous users and should not be represented as such. To move toward that target, the service needs load tests and capacity planning, PostgreSQL with migrations/connection pooling, a durable queue, multiple stateless webhook receivers/workers, object storage for large media, distributed rate limiting, observability/alerts, disaster recovery and provider-approved resource capacity. Shared cPanel + a local SQLite file is not an appropriate final architecture at that scale.