Techloghub - Karma System
TechLogHub's karma system started with a simple schema — one document per user, karma as a single number.
Had to redesign it as usage grew. Here's what forced the change.
What broke down:
→ Needed both a spendable balance AND a lifetime-earned total for the leaderboard — one field couldn't represent both→ Karma events (why someone earned points) had no audit trail — couldn't debug disputes or show users their history→ Leaderboard queries got slower as the single-collection approach scaled past a few thousand users
What changed:
→ Split into karmaBalance (spendable) and totalKarmaEarned (lifetime, leaderboard-facing) as separate fields→ Added a karma_events collection — every point change is logged with reason, timestamp, and source→ Indexed totalKarmaEarned separately for fast leaderboard sorting without touching the main user document
Backfill was the tricky part — had to reconstruct historical totals from existing balances since event logging didn't exist from day one.
Lesson: a "simple" field can work fine until you need to ask two different questions of the same data. At that point, it's not a bug, it's a schema problem.
Anyone else had a schema redesign forced by a feature that seemed small at first?
Comments
No comments yet
Be the first to share your thoughts.