Проєкт / 06

Crypto Game TMA

Особистий проєкт: Telegram-гра для експериментів із фінансовим обліком, Web3 та архітектурою backend.

Роль

Backend Engineer

Період / формат

2026

Статус

Проєктна розробка

Особистий внесок

Спроєктував фінансовий модуль з обліком транзакцій за методом подвійного запису (double-entry bookkeeping) для усунення балансових розбіжностей.
Виніс генерацію та підписання EVM/TON транзакцій в ізольований мікросервіс з обміном повідомленнями через gRPC та RabbitMQ.

Python, FastAPI, PostgreSQL, RabbitMQ, Celery, gRPC, Web3.py, Next.js

01 / Про проєкт

Про проєкт

Розробляв Telegram-гру як особистий проєкт з ідеєю white-label розповсюдження. Експериментував із фінансовим модулем, double-entry ledger та окремим gRPC-сервісом підписання EVM/TON-транзакцій.

02 / Кілька рішень

За гроші відповідає один модуль

Funds керує балансами, резервами та записами ledger. Games використовує типізовані інтерфейси й не змінює фінансові таблиці напряму.

Задачі переживають перезапуск

PostgreSQL зберігає стан задач. RabbitMQ і Celery доставляють роботу, а Redis використовується для тимчасової координації та кешу.

Модулі спілкуються через невеликі інтерфейси

API, ігровий runtime і workers працюють окремими процесами. Підпис транзакцій винесений в окремий gRPC-сервіс.

03 / Екрани продукту

Mini App та адмін-панель

Гравецька частина розрахована на вузький екран Telegram. В адмін-панелі зібрані платежі, ігри, Gifts, користувачі та операційні дані.

Mini App

430 x 932

Адмін-панель

26 screens · 1440 px

Знято з локального застосунку. Для адмін-панелі та живого crash-раунду використані демо-дані.

04 / Архітектура системи

Архітектура системи

Оригінальна документація проєкту російською

Відкрити інтерактивну схему ↗

05 / Деталі backend

Як влаштований backend

Це одна кодова база, але API, realtime-ігри, workers і signer запускаються окремо. Нижче показані частини, які виконують основну роботу.

Що є в backend

Funds

Рахунки, подвійний запис, баланси, резервування, депозити, виведення, конвертації та звірка.

Games

Кейси, слоти та crash, ставки, зобов’язання, відтворювані правила й realtime-події.

Gifts

Каталог, віртуальні й забезпечені Telegram запаси, інвентар, колекції, закупівля та доставка.

Referrals

Реферальні зв’язки, промокоди, партнерський облік, боти та виплати.

App settings

Опубліковані ревізії бренду та серверна перевірка можливостей white-label розгортання.

Jobs and broadcasts

Надійні фонові задачі, доставка сповіщень, lease, повтори й операційний стан.

Кілька цікавих деталей

Депозитні гаманці користувачів

EVM-адреси виводяться із зашифрованої мнемоніки. Index 0 належить master wallet, користувачі отримують додатні індекси за шляхом m/44'/60'/0'/0/{index}. Користувацький ключ може переводити кошти лише в master wallet. У TON використовується один Wallet V4R2 з index 0 та персональним memo.

Фінансова консистентність

PostgreSQL зберігає баланси й стан задач. Подвійний запис, deferred triggers, унікальні ключі операцій, стабільний порядок блокувань і одна зовнішня ApplicationTransaction атомарно фіксують пов’язані зміни. Зовнішній виклик відбувається після durable checkpoint, а неоднозначний результат переходить у reconciliation.

Облік подарунків

Віртуальні Gifts і реальні Gifts із Telegram мають окреме походження. Відкриття кейса резервує приз до видачі. Зниклий зарезервований Gift переходить у reconciliation_required. Намір купівлі або доставки зберігається до виклику Telegram.

Надійні фонові задачі

Celery і RabbitMQ передають лише ID задачі з PostgreSQL. Worker отримує рядок через lease і fencing token та зберігає фінальний стан до ACK. Повторна доставка стає безпечним no-op, а невідомий результат провайдера звіряється без сліпого повтору.

Ізольований підпис транзакцій

Signer володіє зашифрованими мнемоніками та надає derivation і signing через авторизований gRPC. mTLS-ідентичності мають явні capabilities. Політики обмежують мережі, контракти, адреси, суми, gas і fee; відповіді зберігаються для idempotency.

Аудит правил ігор та колекцій

Розіграш колекції зберігає ваги, модифікатори, roll, total weight, обраний item і hash seed. Ставка, максимальна відповідальність, результат, видача призу й outbox-подія фіксуються разом у PostgreSQL.

Карта проєкту

Сфокусоване дерево backend і signer. Згенеровані файли та технічні кеші не показані.

BACKEND / SIGNER

Backend / модульний моноліт

apps/backend/srcroot

main.pyAPI + Telegram bot composition

game_runtime.pyrealtime WebSocket process

core/database · security · tracing · metrics · UOW

modules/bounded contexts

funds/ledger · payments · custody · reconciliation

domain/money and deterministic rules

application/use cases and durable jobs

adapters/EVM · TON · Stars · Alchemy

persistence/typed repositories and models

games/game modes and realtime

api.pypublic commands · schemas · events

domain/fairness · lifecycle · liabilities

application/use cases · rules · funds ports

modes/isolated game implementations

cases/catalog · openings · prize drops

slot/grid · paylines · payouts

crash/rounds · bets · recovery

runtime/WebSocket protocol · event stream

persistence/rules · events · demo state

tests/unit · integration · recovery

gifts/catalog · inventory · delivery

referrals/partners · promo codes · payouts

app_settings/white-label revisions

jobs/ + broadcasts/durable work and delivery

presentation/HTTP and Telegram adapters

worker/Celery transport wrappers

apps/backend/testsunit · integration · architecture

Signer / ізольований gRPC-сервіс

apps/signerisolated process

src/main.pygRPC server

src/service.pyauthenticated RPC methods

src/keys.pyencrypted keys and derivation

src/policy.pychain and transfer limits

src/request_store.pydurable idempotency store

tests/policy · keys · gRPC · request replay

contracts/proto/signershared versioned contract

Frontend і dashboard

Цю частину залишив короткою. Найсильніше я саме в backend.