MagicTask — Gamified Project Management Platform

Overview

MagicTask is the world's first gamified project management platform — a bold reinvention of how teams work together. Where traditional task tools feel like chores, MagicTask turns productivity into an RPG-style progression system, awarding XP, unlocking achievements, and building team leaderboards that actually make people want to open their task manager.

I joined as Lead Full-Stack Engineer during a pivotal growth phase, taking ownership of the real-time collaboration engine, the reward calculation system, and the platform's transition from a monolith to a horizontally scalable microservices architecture.

The Challenge

The founding team had proven product-market fit with a passionate early user base, but the original architecture was cracking under load. A single Node.js server handled everything — WebSocket connections, task mutations, reward calculations, and database writes — all in one process. At 5K concurrent users, it was already showing latency spikes. The roadmap demanded 100K+ concurrent users within 12 months.

The reward algorithm was the most complex piece: every task completion, comment, mention, reaction, and login triggered a multi-step scoring calculation across a user's entire history. Running this synchronously on every action was a non-starter at scale.

Architecture & Technical Decisions

Decoupled Event-Driven Reward Engine

I redesigned the reward system as an async event pipeline. Every user action emits an event to a BullMQ queue. A dedicated reward worker service consumes events, calculates delta XP using a weighted scoring model, and writes to PostgreSQL in batches. This moved reward calculation fully off the critical path — users see instant optimistic UI updates while the worker processes asynchronously within 200ms p99.

• BullMQ with Redis for durable, retryable job queues
• Reward worker scaled independently of the API layer
• Batch DB writes reduced PostgreSQL IOPS by 70%
• Dead-letter queue + Sentry alerts for failed reward jobs

WebSocket Infrastructure at Scale

The original Socket.IO setup used in-memory rooms — fine for a single server, catastrophic for horizontal scaling. I replaced it with a Redis Pub/Sub adapter so any API server instance could publish to any connected client. Combined with sticky sessions at the AWS ALB layer and connection heartbeat pruning, the system handled 100K+ concurrent WebSocket connections across 12 EC2 instances.

• Socket.IO with Redis adapter for cross-instance pub/sub
• AWS ALB with sticky sessions for WebSocket affinity
• Connection pooling and heartbeat timeouts to prevent zombie connections
• Room-based broadcast isolation per workspace to limit fan-out

Database Strategy

PostgreSQL served as the system of record. I introduced read replicas for all analytics and leaderboard queries, relieving the primary of heavy SELECT load. Materialized views refreshed every 5 minutes powered the team leaderboards without real-time aggregation cost. Critical paths (task creation, XP mutations) hit the primary with optimistic locking to prevent race conditions.

Results

• Scaled from 5K to 100K+ concurrent users with zero downtime during the transition
• Reward engine processes 2M+ events per day at <200ms p99 latency
• User retention increased 340% after gamification features shipped (cohort analysis vs. pre-gamification baseline)
• API p95 latency dropped from 1.2s to 85ms after architectural changes
• 99.99% uptime over 12 consecutive months post-launch

What I Learned

This project cemented my belief that premature optimization is a trap — but so is premature pessimism about your architecture. The original monolith wasn't wrong; it was right for its stage. Knowing when and how to evolve architecture without stopping product velocity is the real senior engineering skill. At MagicTask, we never stopped shipping features while rebuilding the engine mid-flight.