Проект / 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.