Дмитрий Ищенко

контекст

Telegram-платформа с инкентивизированными заданиями: пользователи сабмитят выполнение шагов в партнёрских проектах, модераторы валидируют через admin-handlers, раз в месяц система распределяет бюджет по pool-based схеме на основе review-points. Бот отвечает за расчёт распределения, хранение wallet-адресов и broadcast результатов; on-chain settlement выполняется отдельно по результатам PLpgSQL-расчёта. За 7 месяцев — рост с 25k до 63k MAU, более 1M ручных проверок задач.

компромиссы

• Скоринг в PLpgSQL stored procedures vs application-level: вынес в БД — атомарность с записью лидерборда, минус сетевой round-trip и невозможно случайно посчитать половину; цена — сложнее юнит-тестировать, выигрыш — простая аудитируемая SQL-логика, которую можно git-tracking.
• Pool-based распределение (winner_flag + price_if_last) vs flat per-task: pool-схема исключает доминирование одного юзера и держит распределение справедливым на длинном хвосте, требует window-функций SQL.
• Mozilla Fluent через fluentogram vs gettext: Fluent даёт inline pluralization и DSL для биз-фраз; fluentogram даёт async-интеграцию с aiogram. .ftl-локали в репо — текстовый source of truth.
• Jupyter-ноутбук для калибровки месячного бюджета вместо real-time дашборда: дешевле в поддержке (1 ноутбук vs Grafana stack), быстрее итерации формул на исторических данных перед каждым раундом распределения.
• docker-compose вместо k8s: компактный набор сервисов на одном host — k8s overhead не оправдан.

архитектура

Telegram webhook бьёт в bot service на aiogram (с Mozilla Fluent через fluentogram для i18n, ru/en .ftl-локали). Submission/review workflow: пользователь сабмитит выполнение через FSM на Redis, модератор валидирует через admin-handlers. Расчёт выплат полностью в Postgres: набор PLpgSQL stored procedures (compile_leaderboard, compile_monthly_rewards, compile_weekly_results, compile_referred_rewards) применяет pool-based алгоритм (winner_flag + price_if_last поверх review-points) к данным review/submission. Wallet-адреса пользователей хранятся в Postgres; on-chain settlement выполняется отдельным процессом по результатам SQL-расчёта, бот шлёт broadcast с уведомлением о выплате. Audit-модуль логирует операции над балансом. FastAPI/uvicorn под webhook-runner и админскую часть.

результаты

• $138k+ обработано системой выплат за 7 месяцев на 63k+ MAU.
• pool-based reward distribution полностью в SQL — атомарный расчёт, аудитируемая формула.
• >1M ручных проверок задач модераторами через bot-flow.
• i18n: ru/en через Fluent + fluentogram, .ftl-локали как источник правды.
• компактный stack в docker-compose; bot + admin + webhook-runner на одном host.

что вынес

• PLpgSQL stored procedures для финансового скоринга оправданы, когда формула меняется ежемесячно — git-tracked миграции дают чёткую history без application redeploy и атомарность на уровне транзакции.
• Window-функции в SQL (FIRST_VALUE OVER PARTITION, ROWS UNBOUNDED PRECEDING) делают сложные распределения декларативными — то, что в application-коде превратилось бы в imperative loop с ручной агрегацией.
• Fluent + fluentogram ставит DSL-планку для i18n в продуктах с многоязычной аудиторией — pluralization и contextual variants нативно, минус целый класс багов с ручным форматированием.

контекст

EVM-исполнитель транзакций с требованием: высокая вероятность инклюжна в нужный временной интервал (competitive launches, time-sensitive операции). Маршрутизация выбирается под профиль сделки: критичные/чувствительные транзакции идут параллельно в несколько private relay-каналов (одна и та же подписанная tx, первый успех выигрывает по nonce), некритичные — через public mempool с быстрыми RPC-резолверами без overhead релеев.

компромиссы

• Параллельный диспатч в N private relays vs single relay + retry: N релеев = +покрытие за счёт географической / провайдерской диверсификации, цена — N×fee, оправдано только на peak-окнах.
• Public mempool vs private relays per-transaction: для большинства non-competitive отправок public mempool с быстрым RPC-резолвером быстрее и дешевле; private relays — только когда профиль сделки этого требует. Решение принимается per-transaction, не глобально.
• eth_call simulation: используется в dry-run / low-budget тестовых режимах (отлавливает revert до отправки и сохраняет газ при отладке), но НЕ на хот-пути — там +50-100ms latency не оправдан для time-sensitive операций.
• Async nonce-machine с резервированием vs naive next-nonce запрос: peak-отправки требуют preallocated nonce range, иначе RPC-задержка съедает весь выигрыш от параллельности.
• Alloy вместо ethers-rs: Alloy быстрее, типизированнее, лучше поддерживается; миграция с ethers оправдана даже на середине проекта.
• Бизнес-логика swap-плагинов изолирована от ядра (signing/rpc/nonce/gas/submit) — добавление нового DEX = реализация одного trait, без касания executor core.

архитектура

Plugin (DEX swap builder) формирует EvmSwap value object и передаёт его в executor core на Alloy. Core последовательно проходит signing, async nonce-machine с резервированием и submit; gas estimation через EIP-1559, опциональная eth_call simulation для dry-run/тест-режимов. Submit-слой выбирает маршрутизацию per-transaction: критичные tx уходят параллельно в N private relay-каналов (nonce гарантирует, что включение возможно ровно один раз — первый успех выигрывает, остальные no-op), остальные — через public mempool с быстрым RPC-резолвером. Identity-store шарится с Solana-веткой стека через Postgres.

результаты

• высокое покрытие конкурентных временных окон mainnet через параллельный диспатч в private relays.
• гибридная маршрутизация per-transaction: private relays и public mempool используются под профиль сделки, без жёсткой привязки.
• 127 source-файлов в крейте, ядро (signing/rpc/nonce/gas/submit) в одном месте, swap-логика изолирована.
• CLI-бинари: whoami, bench, estimate, buy_once — для оперативной диагностики и разовых отправок.

что вынес

• Async nonce-machine с резервированием — единственный способ держать throughput на peak-отправках. Naive next-nonce request на каждом таске ловит RPC-jitter и съедает преимущество параллельности.
• Чёткое разделение executor core / DEX-плагины (через trait + value object) — каждая новая интеграция занимает 1 день вместо недели.
• Маршрутизация submit-слоя должна быть per-transaction, не глобальной: дефолт private relays на всё = переплата на N×fee, дефолт public mempool на всё = просадка по покрытию на competitive окнах.

контекст

24/7 мониторинг защищённого third-party источника (агрессивный fingerprinting + Cloudflare + динамические DOM-структуры). Цель — извлечение public-видимых данных в реальном времени для собственной аналитики и алертов. Вызовы: anti-bot периодически ужесточается, прокси портятся, сессии срываются. Требование к доступности — высокое, на источнике, который сам по себе не гарантирует SLA.

компромиссы

• Playwright (Chromium) + stealth-патчи vs HTTP-only с подделкой fingerprint: HTTP-only работает быстрее и дешевле, но ломается на каждом обновлении JS-челленджа источника; Playwright дороже в RAM (~1.5GB на инстанс), но устойчивее.
• Persisted cookies + авто-релогин vs fresh login каждую N часов: persisted даёт длинные сессии и низкий fingerprint-риск, но требует cryptography для at-rest-encryption секретов.
• N инстансов с собственным прокси-пулом vs single beefy instance: горизонтальное масштабирование даёт географическую диверсификацию и независимый health-tracking, при бане одного — остальные продолжают; цена — DI и общая БД.
• Auto-exclusion прокси на 15 минут при сетевых ошибках vs immediate retry: 15-минутный кулдаун даёт upstream-провайдеру время восстановиться, не сжигая proxy budget.
• Clean architecture (app/domain/infra/repos/services) для скрейпера — выглядит как overkill для "одного парсера", но окупается, когда N инстансов × M задач × K событий, и нужно поменять источник нотификаций без касания core.

архитектура

N параллельных Playwright-инстансов (Chromium + stealth-патчи) — каждый со своим прокси-пулом и независимым health-tracker (auto-exclusion на 15 мин при сетевых ошибках). Над инстансами — domain layer (repositories + services, DI через dependency-injector, mypy strict). Извлечённые данные нормализуются в общую Postgres, оттуда расходятся в трёх потребителей: notifier (aiogram + discord.py), ML-pipeline (pandas + scikit-learn + UMAP), и дашборд (React 19 + FastAPI). Отдельный health-bot мониторит все три инстанса через sdnotify и шлёт Telegram-алерты при деградациях.

результаты

• 24/7 в проде на anti-bot источнике, который сам по себе не гарантирует доступности.
• N параллельных инстансов с независимым прокси-пулом на каждом (auto-exclusion 15 мин при сетевых ошибках).
• mypy strict + pydantic-settings + dependency-injector — production-grade Python codebase.
• ML-кластеризация участников через UMAP — отдельная аналитическая ценность поверх raw-данных.
• из проекта извлечён публичный open-source toolkit (playwright-stealth-toolkit) на GitHub.

что вынес

• Stealth-патчи устаревают быстрее, чем кажется — нужна моментальная диагностика fingerprint-блока (отдельный health-check на каждом инстансе) и быстрый канал обновления stealth-параметров.
• Persisted cookies + auto-relogin pattern радикально снижает fingerprint-риск по сравнению с fresh-login каждые N часов — рекомендую как default для long-running scraping.
• Clean architecture окупается на 4-й неделе работы 24/7, когда нужно поменять одно и не задеть остальное; на старте кажется bureaucratic.