Dmitrii Ishchenko

context

A Telegram platform with incentivized tasks: users submit step completions for partner projects, moderators validate them via admin handlers, and once a month the system distributes the budget through a pool-based scheme on top of review-points. The bot is responsible for computing the distribution, storing wallet addresses and broadcasting results; on-chain settlement is done separately using the PLpgSQL output. Over 7 months — growth from 25k to 63k MAU, more than 1M manual task reviews.

tradeoffs

• Scoring inside PLpgSQL stored procedures vs application level: moved it into the DB — atomicity with the leaderboard write, no network round-trips, no way to accidentally compute half the picture; the cost is harder unit testing, the win is simple auditable SQL logic that can be git-tracked.
• Pool-based distribution (winner_flag + price_if_last) vs flat per-task: a pool scheme prevents a single user from dominating and keeps distribution fair across the long tail, at the cost of needing SQL window functions.
• Mozilla Fluent through fluentogram vs gettext: Fluent gives inline pluralization and a DSL for business phrases; fluentogram gives async integration with aiogram. The .ftl locales in the repo are the textual source of truth.
• Jupyter notebook for monthly budget calibration instead of a real-time dashboard: cheaper to maintain (1 notebook vs a Grafana stack), faster iteration on formulas against historical data before each distribution round.
• docker-compose over k8s: a compact set of services on one host — k8s overhead is not justified.

architecture

The Telegram webhook hits the bot service on aiogram (with Mozilla Fluent through fluentogram for i18n, ru/en .ftl locales). Submission/review workflow: a user submits a completion via FSM on Redis, a moderator validates it through admin handlers. Payout computation lives entirely in Postgres: a set of PLpgSQL stored procedures (compile_leaderboard, compile_monthly_rewards, compile_weekly_results, compile_referred_rewards) applies a pool-based algorithm (winner_flag + price_if_last on top of review-points) to review/submission data. User wallet addresses are stored in Postgres; on-chain settlement runs as a separate process over the SQL output, the bot then broadcasts a payout notification. The audit module logs balance operations. FastAPI/uvicorn powers the webhook runner and admin area.

results

• $138k+ processed through the payout system over 7 months at 63k+ MAU.
• pool-based reward distribution fully in SQL — atomic computation, auditable formula.
• >1M manual task reviews by moderators through the bot flow.
• i18n: ru/en via Fluent + fluentogram, .ftl locales as the source of truth.
• compact stack in docker-compose; bot + admin + webhook runner on a single host.

takeaways

• PLpgSQL stored procedures for financial scoring pay off when the formula changes monthly — git-tracked migrations give clean history without an application redeploy and atomicity at the transaction level.
• SQL window functions (FIRST_VALUE OVER PARTITION, ROWS UNBOUNDED PRECEDING) make complex distributions declarative — what would otherwise become an imperative loop with manual aggregation in application code.
• Fluent + fluentogram raises the bar for i18n in products with a multilingual audience — native pluralization and contextual variants, killing a whole class of manual-formatting bugs.

context

An EVM transaction executor with a single requirement: a high probability of inclusion in the target time window (competitive launches, time-sensitive operations). Routing is chosen per trade profile: critical / time-sensitive transactions go in parallel into several private relay channels (the same signed tx, first success wins by nonce); non-critical ones go through the public mempool with fast RPC resolvers and no relay overhead.

tradeoffs

• Parallel dispatch into N private relays vs single relay + retry: N relays = better coverage through geographic / provider diversification, the cost is N×fee, only justified during peak windows.
• Public mempool vs private relays per-transaction: for most non-competitive submits, the public mempool with a fast RPC resolver is both faster and cheaper; private relays come in only when the trade profile requires it. The decision is made per transaction, not globally.
• eth_call simulation: used in dry-run / low-budget test modes (catches reverts before submission and saves gas during debugging), but NOT on the hot path — the +50-100ms latency is not worth it for time-sensitive operations.
• Async nonce machine with reservations vs a naive next-nonce request: peak submissions require a preallocated nonce range, otherwise RPC jitter eats up the entire parallelism win.
• Alloy over ethers-rs: Alloy is faster, more strongly typed, and better maintained; migrating from ethers is worth it even mid-project.
• Swap-plugin business logic is isolated from the core (signing/rpc/nonce/gas/submit) — adding a new DEX = implementing a single trait, no touching the executor core.

architecture

A plugin (DEX swap builder) produces an EvmSwap value object and passes it into the executor core on Alloy. The core walks through signing, an async nonce machine with reservations, and submit; gas estimation uses EIP-1559, with optional eth_call simulation for dry-run / test modes. The submit layer picks routing per transaction: critical tx fan out in parallel to N private relay channels (the nonce guarantees inclusion can happen exactly once — first success wins, the rest become no-ops), the rest go through the public mempool with a fast RPC resolver. The identity-store is shared with the Solana branch of the stack through Postgres.

results

• high coverage of competitive mainnet time windows via parallel dispatch into private relays.
• hybrid per-transaction routing: private relays and public mempool are used based on trade profile, no hard binding.
• 127 source files in the crate, core (signing/rpc/nonce/gas/submit) in one place, swap logic isolated.
• CLI binaries: whoami, bench, estimate, buy_once — for operational diagnostics and one-off submits.

takeaways

• An async nonce machine with reservations is the only way to keep throughput during peak submits. A naive next-nonce request on every task hits RPC jitter and eats the parallelism win.
• A clean executor core / DEX-plugin split (via trait + value object) — each new integration takes a day instead of a week.
• Submit-layer routing has to be per-transaction, not global: defaulting to private relays for everything = overpaying N×fee; defaulting to public mempool for everything = losing coverage on competitive windows.

context

24/7 monitoring of a protected third-party source (aggressive fingerprinting + Cloudflare + dynamic DOM structures). The goal is to extract publicly visible data in real time for in-house analytics and alerts. Challenges: anti-bot tightens periodically, proxies go bad, sessions drop. High availability requirement on top of a source that itself does not guarantee any SLA.

tradeoffs

• Playwright (Chromium) + stealth patches vs HTTP-only with forged fingerprint: HTTP-only is faster and cheaper but breaks on every JS-challenge update from the source; Playwright costs more RAM (~1.5GB per instance) but is much more resilient.
• Persisted cookies + auto-relogin vs fresh login every N hours: persisted gives long sessions and low fingerprint risk, but requires cryptography for at-rest encryption of secrets.
• N instances with their own proxy pool vs a single beefy instance: horizontal scaling gives geographic diversification and independent health tracking — when one gets banned, the others keep going; the cost is DI plus a shared DB.
• Auto-exclusion of proxies for 15 minutes on network errors vs immediate retry: a 15-minute cooldown gives the upstream provider time to recover without burning through the proxy budget.
• Clean architecture (app/domain/infra/repos/services) for a scraper — looks like overkill for "just a parser", but pays off when it is N instances × M tasks × K events, and you need to swap the notification source without touching the core.

architecture

N parallel Playwright instances (Chromium + stealth patches) — each with its own proxy pool and independent health tracker (auto-exclusion for 15 minutes on network errors). On top of the instances sits the domain layer (repositories + services, DI through dependency-injector, mypy strict). Extracted data is normalized into a shared Postgres, from which it flows to three consumers: notifier (aiogram + discord.py), ML pipeline (pandas + scikit-learn + UMAP), and dashboard (React 19 + FastAPI). A separate health bot monitors all three instances via sdnotify and pushes Telegram alerts on regressions.

results

• 24/7 in production against an anti-bot source that itself does not guarantee availability.
• N parallel instances with an independent proxy pool per instance (auto-exclusion 15 min on network errors).
• mypy strict + pydantic-settings + dependency-injector — production-grade Python codebase.
• ML clustering of participants via UMAP — a standalone analytical layer on top of raw data.
• spun off a public open-source toolkit (playwright-stealth-toolkit) on GitHub from this project.

takeaways

• Stealth patches go stale faster than you think — you need instant diagnostics for fingerprint blocks (a dedicated health-check per instance) and a fast channel for updating stealth parameters.
• The persisted cookies + auto-relogin pattern dramatically reduces fingerprint risk compared to fresh-login every N hours — I recommend it as the default for long-running scraping.
• Clean architecture pays off in week 4 of 24/7 operations, when you need to change one thing without touching the rest; on day one it looks bureaucratic.