← Back to overview
logo
OpenQuest
Telegram Mini App · Co-Founder & Tech Lead · May 2024 – Feb 2025
500K
MAU
2K
RPS peak
$150K+
Revenue
$150
Monthly infra cost
What We Built
No-code quest platform built as a Telegram Mini App — enabling projects to create verifiable on-chain engagement campaigns for their communities.
Integrated deep linking, bot feedback loops, and story sharing to drive viral growth.
Delivered $150K+ revenue through B2B onboarding, cross-marketing, and paid campaigns.
- Launched with co-founders. My responsibility: entire technical architecture — backend design, infrastructure, TON smart contract integrations.
- Integrated Telegram-native features: deep linking, bot feedback, story sharing for viral growth loops.
- Built analytics, release automation, and product iteration pipeline based on user feedback.
How 500K MAU Ran on $150/mo
We designed for scale from day one — we had strong reasons to expect a large user wave on launch, and we were right.
The goal was: survive the spike, then iterate. Here's what made it work.
Architecture Principles
- Stateless services everywhere — every service designed to scale horizontally without shared state. No sticky sessions, no local state.
- Minimal transactions, fast paths — account creation completes with the minimum number of DB operations. Everything else (referral linking, DM notifications, etc.) is offloaded to RabbitMQ workers asynchronously.
- Conservative isolation levels — deliberately avoided high isolation in Postgres transactions to prevent unnecessary lock contention.
- Read-only replica for all heavy reads — long-running queries routed exclusively to RO replica. Primary DB handled only writes.
- Redis distributed locks before every transaction — before any Postgres transaction starts, a Redis lock is acquired. Protects against both deadlocks and abuse (double-submission, etc.).
Pre-Launch Preparation
- Scaled up before launch — provisioned capacity with headroom. No autoscaling surprises on day one.
- Observability ready before go-live — metrics and log collection configured and tested before launch, not after the first incident.
- Index analysis before launch — used pg_stat_statements + PgHero on dev environment to identify missing indexes. One missing index can cause deadlocks or degrade entire-system performance.
- Post-launch index re-check (critical) — re-validated indexes after ~1 day of real traffic. With sparse data, Postgres may choose seq scan over index scan; from ~200K rows this becomes a bottleneck. Real traffic revealed patterns dev data couldn't simulate.
Infrastructure
- Kubernetes on DigitalOcean (launched), migrating to Hetzner Cloud — significantly cheaper at scale while DigitalOcean was right for the fast start.
- Cloudflare in front for DDoS protection and CDN.
- nginx as load balancer.
- Postgres — primary storage with RO replica.
- Redis — distributed locks + caching.
- RabbitMQ — async worker queue for all non-critical user-flow work.
- Node.js backend — chosen for team expertise + ecosystem fit for Telegram + TON integration.
- TON smart contracts — on-chain verifiable quest completion.
Tech Stack