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

контекст

Telegram-платформа с инкентивизированными заданиями: пользователи выполняют шаги в партнёрских проектах, модераторы валидируют выполнение, система раз в месяц распределяет бюджет по сложной скоринговой схеме (ранги 1–100, накопленные очки с мультипликатором 1.1x–2.5x, 15% реферальная программа). Выплаты — on-chain в USDT на Arbitrum, требование: ноль дублей выплат при retry/перезапуске воркера, идемпотентность всех операций. За 7 месяцев — рост с 25k до 63k MAU, 1M+ ручных проверок задач.

компромиссы

• Скоринг в PLpgSQL stored procedures vs application-level: вынес в БД — атомарность с записью лидерборда, минус сетевой round-trip; минус — сложнее юнит-тестировать, плюс — невозможно случайно посчитать половину.
• Batched on-chain payouts (раз в день) vs immediate per-claim: батч экономит газ ×10 и снижает шум блокчейна, но требует idempotency keys и persistent dedup-таблицы; выбрал batched после первой недели работы immediate-схемы.
• Mozilla Fluent vs gettext для i18n: Fluent даёт inline pluralization и DSL для биз-фраз; aiogram-i18n + Fluent — нативно асинхронно. .ftl-файлы в репо как текстовый source of truth.
• Jupyter-аналитика для месячных бюджетов вместо real-time дашборда: дешевле в поддержке (1 ноутбук vs Grafana stack), быстрее итерации формул при ежемесячной калибровке.
• docker-compose вместо k8s: 3 сервиса (bot / payout-worker / moderation-admin), один host — k8s overhead не оправдан.

архитектура

   ┌─────────────┐   aiogram     ┌──────────────┐   stored proc  ┌────────────┐
   │  Telegram   │ ─────────────▶│   bot svc    │ ─────────────▶│ Postgres   │
   │  webhook    │               │  + Fluent    │   (PLpgSQL    │ (scoring,  │
   └─────────────┘               │   i18n       │   leaderboard)│  audit log)│
                                 └──────┬───────┘                └─────┬──────┘
                                        │                              │
                                        ▼                              ▼
                            ┌──────────────────┐          ┌─────────────────────┐
                            │  moderation       │          │   payout worker     │
                            │  admin (manual    │          │   (idempotent       │
                            │  ~1M tasks/qtr)  │          │   batched USDT      │
                            └──────────────────┘          │   on Arbitrum)      │
                                                          └──────────┬──────────┘
                                                                     │ web3.py
                                                                     ▼
                                                          ┌─────────────────────┐
                                                          │  smart contract     │
                                                          │  0xFd08…Cbb9        │
                                                          └─────────────────────┘

• idempotency: payout_id = hash(user_id, period, contract_addr) — UNIQUE-индекс в Postgres, повторный submit = no-op.
• audit_log пишется в той же транзакции, что и balance-update — ноль шансов на пропавшую выплату.

результаты

• $138k+ обработано платёжной системой за 7 месяцев на 63k+ MAU.
• 0 дублей выплат за всё время работы (1M+ операций модерации, тысячи batched-payouts).
• i18n покрытие через Fluent — 7.6% репозитория = .ftl-локали.
• до 25k просмотров на пост в продуктовом канале (telegram analytics).
• компактный stack: 3 сервиса в docker-compose, 1 host, ноль downtime по платежам.

что вынес

• Идемпотентность через UNIQUE-индекс в БД (а не in-memory dedup) — единственный способ выжить при перезапусках воркера выплат и retry-сценариях.
• PLpgSQL stored procedures для финансового скоринга оправданы, когда формула меняется ежемесячно — git-tracking миграции дают чёткую history без application redeploy.
• Fluent ставит DSL-планку для i18n в Telegram-продуктах с шестизначным денежным оборотом — pluralization и contextual variants нативно, минус целый класс bug-ов.

контекст

EVM-исполнитель транзакций с требованием: высокая вероятность инклюжна в нужный временной интервал (competitive launches, time-sensitive операции), без раскрытия транзакции в публичном mempool. Решение — параллельная отправка через private relay-каналы (несколько параллельных venue), идентичная транзакция идёт в каждый. Первый успех выигрывает, остальные no-op (одна и та же tx по nonce).

компромиссы

• Параллельный диспатч в N релеев vs single relay + retry: N релеев = +1-2% покрытие за счёт географической / провайдерской диверсификации, цена — N×fee, но это окупается на peak-окнах.
• eth_call simulation перед каждой отправкой vs blind submit: simulation добавляет ~50-100ms latency, но отсекает гарантированные revert — net latency на успешных отправках ниже за счёт отсутствия reverted-attempts.
• 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    │  EvmSwap value object
   │ (DEX swap   │ ──────┐
   │  builder)   │       │
   └─────────────┘       ▼
                  ┌──────────────────┐  eth_call    ┌────────┐
                  │   executor core  │ ───────────▶│  RPC    │
                  │  (Alloy)         │   (sim)      │  pool   │
                  │  ┌─────────────┐ │              └────────┘
                  │  │ signing     │ │
                  │  │ nonce mgr   │ │
                  │  │ gas est.    │ │      parallel dispatch
                  │  │ submit      │ │ ──┬───▶ ┌──────────────┐
                  │  └─────────────┘ │   │     │  private     │
                  └──────────────────┘   │     │  relay #1    │
                                         │     └──────────────┘
                                         ├───▶ ┌──────────────┐
                                         │     │  private     │
                                         │     │  relay #2    │
                                         │     └──────────────┘
                                         └───▶ ┌──────────────┐
                                               │  private     │
                                               │  relay #3    │
                                               └──────────────┘

• Все relay-каналы получают одну и ту же подписанную tx — nonce гарантирует, что включение возможно ровно один раз.
• Identity-store шарится между EVM-веткой и основным sniper-hub через Postgres — кошельки и команды одни и те же.

результаты

• 97% покрытие целевых временных окон mainnet через параллельный диспатч.
• 0 leaks в публичный mempool — приватные релеи + предварительная симуляция.
• 127 source-файлов в крейте, ядро (signing/rpc/nonce/gas/submit) в одном месте, swap-логика изолирована.
• CLI-бинари: whoami, bench, estimate, buy_once — для оперативной диагностики и разовых отправок.

что вынес

• Симуляция через eth_call перед submit обязательна, не "nice-to-have" — отсекает revert'ы и сохраняет газ. Latency-цена оправдана на скейле.
• Async nonce-machine с резервированием — единственный способ держать throughput на peak-отправках. Naive next-nonce request на каждом таске ловит RPC-jitter и съедает преимущество параллельности.
• Чёткое разделение executor core / DEX-плагины (через trait + value object) — каждая новая интеграция занимает 1 день вместо недели.

контекст

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

компромиссы

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

архитектура

      ┌─────────────────────────────────────────────────────────┐
      │  3 × Playwright instance (Chromium + stealth)            │
      │  ┌────────────┐   ┌────────────┐   ┌────────────┐        │
      │  │ instance 1 │   │ instance 2 │   │ instance 3 │        │
      │  │ + proxy×3  │   │ + proxy×3  │   │ + proxy×3  │        │
      │  └─────┬──────┘   └─────┬──────┘   └─────┬──────┘        │
      └────────┼────────────────┼────────────────┼───────────────┘
               │                │                │
               ▼                ▼                ▼
        ┌──────────────────────────────────────────────────┐
        │     domain layer (repositories + services)       │
        │     DI via dependency-injector, mypy strict      │
        └────────────────────────┬─────────────────────────┘
                                 │
                ┌────────────────┼────────────────┐
                ▼                ▼                ▼
         ┌────────────┐   ┌────────────┐   ┌──────────────┐
         │ Postgres   │   │  notifier  │   │  ML pipeline │
         │ + Alembic  │   │  (TG / DC) │   │ pandas+UMAP  │
         └────────────┘   └────────────┘   └──────┬───────┘
                                                  │
                                                  ▼
                                         ┌─────────────────┐
                                         │   dashboard     │
                                         │  React 19 +     │
                                         │  FastAPI        │
                                         └─────────────────┘

• Каждый инстанс имеет собственный прокси-пул и независимый health-tracker; общая Postgres — для нормализованных данных и аналитики.
• health-bot отдельным сервисом мониторит все 3 инстанса через sdnotify + Telegram-алерты при деградациях.

результаты

• 24/7 uptime с downtime < 0.5%/мес на anti-bot источнике, который сам по себе не гарантирует доступность.
• 3 параллельных инстанса × ~3 прокси (auto-exclusion 15 мин при ERR_CONNECTION_CLOSED / ERR_TIMED_OUT).
• 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.