Case Study · 2019 — Present
Worldwide Discord Platform
A real-time community platform with an economy system, games, and events — serving 59,028 members with 3,940+ daily active users. Built from scratch. No playbook.
System Architecture — Why Three Languages
Three languages, one system
The system has three layers. Each was built in a different language — not to show off, but because each layer has fundamentally different requirements that made different tools correct.
Python
Discord GatewayHandles the Discord event stream. asyncio fits naturally with Discord's WebSocket gateway — thousands of concurrent events, all I/O bound.
Rust
Data Access LayerHandles all database operations and real-money transactions via Axum. GC pauses are unacceptable in a payment path.
Next.js
Web DashboardServer-side rendered admin dashboard for monitoring server economy, user stats, and event management.
The Database Evolution — Driven by Real Failures
Six databases. Real reasons.
This is the most honest part of the case study. Every database migration happened because something broke, something scaled poorly, or something cost too much latency.
JSON files can't handle concurrent writes. Multiple economy transactions crashing the bot was the forcing function to learn proper databases. Chose MongoDB's sharded cluster specifically for write throughput.
As member count grew, read latency became noticeable in user-facing interactions. Redis caching for hot data (active user economy states) brought response times down significantly.
The economy system developed complex relational requirements — transactions, balances, event histories — that document stores aren't built for. Migrated to PostgreSQL while keeping Redis as the caching layer.
Built the Rust Data Access Layer with gRPC for Python communication. Then took it further: embedded libSQL directly inside the Rust process to eliminate network round-trips for the most latency-sensitive operations entirely.
Wasn't satisfied with off-the-shelf Redis behavior for specific caching patterns. Built parts of a custom Redis implementation to achieve better results for the specific access patterns of the economy system.
Economy Design — Engineering Meets Behavioral Psychology
Designing for real stakes
“A virtual economy with 59,028 participants behaves like a real economy. Inflation, exploitation, reward psychology, and trust — all of it applies.”
Inflation Prevention
Controlling money supply through sinks and faucets — events that remove currency must balance events that generate it.
Exploit Detection
Rate limiting, anomaly detection on transaction patterns, and rollback mechanisms for economic exploits.
Reward Psychology
Variable ratio reinforcement schedules in gambling and games. Daily streaks. Loss aversion mechanics. Applied behavioral economics.
Real Money Bridge
Real currency purchase flow via Axum API. Trust, security, and UX around financial transactions in a gaming context.
What Went Wrong — The Honest Section
What actually went wrong
Anyone can list achievements. Only someone who actually built something can describe what they got wrong.
The JSON File Crash. In the early days, user data lived in a raw JSON file. The bot asynchronously read and wrote virtual currency balances — concurrent access crashed it multiple times a day. Users would lose currency mid-transaction. This was the forcing function to learn databases properly: the fix wasn't a patch, it was a full migration to MongoDB's sharded cluster, chosen for write throughput. Lesson: storage choices that seem “good enough” at small scale become architectural liabilities the moment concurrency enters the picture.
The Cache Bug Incident. A bug in the Redis cache layer caused three days of user economy data to be lost permanently. Partial recovery from logs was possible but not complete. Response: publicly acknowledged the issue to the 59,028-member community, compensated affected users with virtual currency. Long-term fix: added comprehensive test coverage, log points throughout the transaction path, and auto-recovery mechanisms. Lesson: transparency with users is not optional. Systems fail. Response to failure is what builds trust.
What's Next
What's Next
Five years of building Worldwide taught me that the most interesting engineering problems live at the intersection of systems design, behavioral economics, and distributed data. The next step is taking these skills into teams and environments that operate at real scale — distributed systems, high-reliability infrastructure, companies where architecture decisions matter. The next platform won't be a Discord bot. But the same thinking will apply. Read the full story →