Skip to the content

Projects02 / 07 · content automation · 2023–2026

DNA 02

A media business runs dozens of Telegram channels. This platform runs them for it — collecting, cleaning, rewriting, scheduling, publishing and billing, unattended.

Tech lead · architect · PM · devops
Skip to the engineering
In plain words

By hand this is not hard — it is impossible

Thousands of media businesses live inside Telegram. One owner may hold dozens of channels and has to feed every one of them every day: find material, strip out somebody else’s ads, rewrite the text, schedule the post, greet new subscribers, sell ad slots, count the money.

The owner connects their channels and sources once, sets the rules, and the platform takes over: around the clock, weekends included, with nobody at the console. Each customer even gets their own branded bot, created and maintained by the platform itself.

Why it is genuinely hard. Telegram has no official API for this. The platform keeps a fleet of 61 real accounts on the low-level protocol — and Telegram can ban any of them for behaving oddly. So most of the engineering is not “ship a feature”, it is “do not break”: rate budgets, fingerprint separation, ban handling, session recovery — the system heals itself while the owner sleeps.

For engineers

A headless monolith with five routes and a self-healing userbot fleet

200k lines of Ruby across 1,100+ service objects and 45 tables, with roughly two lines of test for every line of code.

Headless monolith

No views, no JS build, no REST API — five routes total. The whole admin and user panel is a state machine inside Telegram: 200k lines of Ruby, 1,100+ service objects, 45 tables.

Two delivery pipelines

Live mirroring (listener → clone per channel → autopost) and cursor-based drip backfill through source history. They receive differently-shaped data, so every capture bug is verified in both.

Userbot fleet on native TDLib

Two sessions per account — one reads, one acts — all listeners under one supervisor with a reconciler that picks up new accounts without a restart. Join budgets, per-account device fingerprints, flood-wait pacing, membership reconciliation.

Semantic dedup & ad detection

1536-dim embeddings inline in the content table with an HNSW index; per-channel AI prompts composed at runtime from JSONB, so tuning needs no deploy.

Incidents worth reading

FD exhaustion (951 open at a 1,024 soft limit) took the supervisor down for 11 hours → limits raised, FD headroom monitored. glibc arena fragmentation cost ~1 GB → jemalloc with decay tuning. 498 per-bot systemd services collapsed into one supervisor.

Quality gate

14,000+ RSpec examples, nearly two lines of test per line of code, four custom RuboCop cops, strict loading on by default, and an automated AI review of every pull request against an eight-point checklist.
429
deploys
1,245
tickets · 6,800 h logged
90%
of merge commits
20
custom monitoring checks
On the reach figure: 33M+ is the sum of subscriber counts across managed channels, not unique people — around 7M distinct Telegram accounts have passed through the platform. I state both because the first number flatters and the second is true.

Who worked on it · 6 contributors

Danyil Shkoropad

tech lead · architect · PM · 2023–2026
  • Architecture, product decisions and 90% of merge commits.
  • Ran the Python→Ruby, Rails 7.2→8.1 and PostgreSQL 16→18 migrations personally.

Mykhail Yun

co-founder · product · 2023–2026
  • Found the customers first: dozens of channel owners interviewed before a line was written, then the spec.
  • Pricing and the ad campaigns behind ×20 customer growth in 14 months.

Nataliia Makarenko

backend · data · 2025–2026
  • The Gemini embedding pass and the HNSW index on the 1536-dimension column it writes to.
  • Background jobs and the backup routine that runs behind all of it.

Oleksii Mikhno

fullstack · 2025–2026
  • Panels inside the Telegram state machine — the product has five HTTP routes and no views.
  • Billing screens and the customer-facing bot factory flows.

Oleksandr Shemberko

backend · reviewer · 2025–2026
  • The customer’s own posts — creation, schedule, per-channel settings — and the ad-reservation service.
  • Premium payment menus and the free/premium split; reviewed 105 of his colleagues’ pull requests.

Claude

pull request review · 2026
  • Automated review of every pull request against an eight-point checklist, inline in the diff.
  • Advisory only. Two humans still have to approve before anything merges.

Read to the end and want to talk it over?

rubyco.in