DeltaCrownEsports Ecosystem Platform
An end-to-end esports platform: tournaments, teams, ranking, points economy, and a competitive hub — designed operator-first.
What it had to solve.
Bangladeshi esports lived inside Facebook groups and Discord brackets — registrations in DMs, prize distribution opaque, no canonical ranking, and operators stitching tournaments together by hand. The system needed to turn that improvisation into infrastructure: a single source of truth for events, teams, results, and economy, with surfaces for both players and the people running the show.
How the pieces fit together.
A Django service layer fronts a relational core; Redis handles session and ranking caches. Django templates with server-side rendering deliver the player-facing surfaces, while a dedicated operator console sits on top of the same models with elevated RBAC.
The surfaces operators and players actually touched.
Tournament Engine
The heart of the platform — events, brackets, scheduling, results, and reward pipelines as first-class models.
- Six formats: single & double elimination, round robin, Swiss, group + playoff, battle royale
- Bracket auto-generation with seed inputs and tie-breakers
- Match check-in windows + auto-forfeit timers
- Operator overrides logged as audit events
Team & Roster Management
Teams as durable objects — invites, role transitions, eligibility checks, and game-specific roster constraints.
- Invite + accept flow with TTLs
- Captain transfer + co-captain delegation
- Per-game minimum roster validation at registration
- Team history record retained across season resets
Crown Points & DeltaCoin
Two economies on the same ledger — Crown Points for ranking, DeltaCoin as a soft currency for entries and rewards.
- Event-sourced ledger — every credit / debit is auditable
- Idempotent grant operations safe under operator retries
- Decay rules per game season so old wins fade
- Read-time projections cached in Redis for the leaderboard
Competitive Hub
Showdown, Missions, Bounty, and Dropzone — meta-modes layered on top of the core economy.
- Mode-specific reward tables wired into the ledger
- Quest progression tracked against participation events
- Bounty matches as inverted brackets with stake escrow
- Operator dashboard for live mode tuning
Operator Console
A dedicated operator-side app — admins, organizers, and judges working against the same data the player UI reads from.
- Granular RBAC per workflow (verify, dispute, reward, override)
- Verification queues for registration and submission proofs
- Per-team audit timeline with read-only filter views
- Action log retained even after season resets
Choices that shaped the build.
Relational core, not a NoSQL stew
Tournaments, teams, and ledger entries are inherently relational — joins, constraints, and transactions earn their keep. PostgreSQL with composite indexes for ranking queries beat a 'flexible' document store on every read path I tried.
Service layer between views and ORM
Django views stay thin. Domain logic lives in service modules with explicit inputs and outputs — easier to test, easier to reuse from background workers and the operator console.
Event-sourced economy
Crown Points and DeltaCoin are write-only ledgers; balances are projections. Reconciliation, refunds, and disputes become reversible operations instead of destructive edits.
Operator-first design
Every player workflow has an operator counterpart with audit trails. The system was built knowing humans need to intervene; the goal was to make intervention safe and observable, not impossible.
RBAC scoped to actions, not pages
Permissions live on the verbs (`verify_payment`, `override_result`, `settle_reward`) — not on URL paths. The same admin UI shows or hides workflows depending on the operator's grants.
Server-side pagination + cached projections
The leaderboard, team list, and tournament archive all use cursor pagination with Redis-cached projections. Cold start aside, response times stay flat as data grows.