Project analysis / project analysis
GrandCombat: analysing Telegram Mini App backend scaling
In a Telegram game, a fast screen depends on what happens after every user action. Using GrandCombat's published scope, we examine which backend responsibilities to analyse separately and how to turn expected traffic into testable scenarios.
What the published case establishes
GrandCombat MiniApp's scope included onboarding, tasks, rewards, progress, referrals and TON Connect. Backend work covered architecture for high concurrency, caching, queues, Socket.IO, analytics and load monitoring. The listed stack includes NestJS, MongoDB and Redis.
This article uses the public project description. Infrastructure topology, instance sizes, collection schemas and profiling results are not disclosed here. The examples below are our engineering recommendations for comparable workloads, rather than a reconstruction of private production code.
Separate action confirmation from its consequences
For a game, it helps to describe authorisation, recording the result and follow-up work separately. Granting a reward should not depend on whether an analytics report has finished updating. At the same time, the interface should not display final success before the server confirms it.
During design, we list operations for which a repeated request could be harmful: a reward claim, referral bonus or balance change. Each needs an agreed way to recognise the same action and avoid applying it twice.
text
Mini App action → session and rule checks → record result
→ user response
→ background work and analytics
Illustrative responsibilities, not GrandCombat's production topology.Decide what to cache and what remains authoritative
A useful cache candidate is information read frequently with a clear tolerance for stale data. Task definitions and a user's completion record have different requirements. A cache should not independently determine whether a reward can be claimed again.
| Category | Design question |
|---|---|
| Task catalogue | How quickly must an administrator's change appear? |
| User progress | Which record confirms that an action completed? |
| Leaderboard | Is delayed updating acceptable, and is its timestamp visible? |
| Session | What happens after access is revoked or expires? |
Queues and real-time need their own failure scenarios
A background job needs an owner, retry limits and a way to surface terminal failure. Idempotency means repeating a job does not change its final outcome again. This matters especially for tasks with business consequences.
For a real-time interface, test disconnects and a returning user. After reconnecting, the client should recover current state instead of relying only on events that may have passed during the interruption.
Prepare a load test before the next campaign
A concurrent-user number alone does not describe workload. We suggest separating sign-in, progress reads, active interactions, task completion and reconnects. Each needs an expected rate, acceptable latency and a success condition.
- Test a sign-in wave after a Telegram announcement.
- Repeat one action and verify the final state.
- Delay background processing and check that operators can see the problem.
- Disconnect and reconnect real-time sessions without losing progress.
- Associate API errors, latency and queue delay with a specific workload.
Sources and context
Working through a similar problem?
Tell us about your product, current constraints and intended outcome. We will identify a concrete next step.