Backend Module Map

TL;DR -The backend is split into focused modules, each responsible for one slice of the product (auth, chat, live rooms, the wallet, and so on). The wallet module is the financial heart and gets extra care.

Who this is for -Product & Business: skim "What a module is" and the inventory table to see the shape of the product. Engineering & Backend: the full table, the cross-cutting pieces, and the wallet deep-dive.

What a module is

The backend is built with NestJS, a framework that encourages you to organize code into modules -self-contained bundles that each own one area of the app. One module handles logging in, another handles chat, another handles live rooms, and so on. Grouping code this way keeps each concern isolated and easy to reason about.

Each module owns three kinds of code: controllers (the entry points that receive requests), services (the logic that does the work), and DTOs (the definitions of what a valid request looks like). Anything shared across modules -the database connection, login checks, security settings -lives in a common area (backend/src/common/).

The backend lives in backend/src/modules/.

Module inventory

Here's the full list of modules and what each one is responsible for. The right column lists the main API endpoints (the URLs the app calls) or gateways (the live channels) each module exposes.

Cross-cutting pieces (backend/src/common/)

Some concerns aren't owned by any single module because every module needs them -the database connection, the login check on protected endpoints, and the guardrail that rejects malformed requests. These shared pieces live in backend/src/common/.

• prisma/prisma.service.ts -the singleton Prisma client, injected everywhere; also hosts $transaction helpers. (Prisma is the tool the backend uses to talk to the PostgreSQL database.)
• auth/jwt-auth.guard.ts -bearer-token guard used by every authenticated controller; decorates requests with AuthenticatedUser (userId, role). In plain terms: it checks the caller's login token before the request is allowed through.
• Global ValidationPipe (in main.ts) -whitelist: true, forbidNonWhitelisted: true, transform: true. Every request body must match its DTO exactly. Webhook endpoints that accept third-party payload shapes (Pub/Sub, Apple notifications) take untyped bodies deliberately so the pipe skips them, then parse defensively by hand.

Wallet module in detail

The wallet module is where all the money lives, so it deserves a closer look. It handles buying coins, spending them on gifts, converting earnings, paying out creators, and processing refunds -and it double-checks every purchase with Apple or Google before crediting anyone. Here's how its responsibilities are split across files:

Every service has a matching .spec.ts test file. The wallet test suite is deliberately thorough because the cost of a money bug is high; it covers purchase idempotency (a receipt can't be counted twice), cross-account replay rejection (a receipt from one account can't credit another), store-fee modeling, gift spend rules, settlement, and refund clawback.

Related pages

• System Architecture -how the backend fits with everything else.
• Data Model -the database tables these modules read and write.
• The economy -the money rules the wallet enforces.