The Parallel — An Infinite MetaverseBack-end Developer LeaderOct 2021 — Nov 2022

Metaverse platform APIs

Cube → NFT uniqueness + game relay — craftable characters 20³ → 100³; compare two cubes ≤ ~2 min. Concurrent ~20, peak ~100, write-heavy.

Lang
  • Node.js
  • TypeScript
Data
  • Kafka
  • Redis
  • MongoDB
Tool
  • Web3 / blockchain
Others
  • API design

Intro

Metaverse backend focused on validating craftable-character cubes into NFTs with uniqueness guarantees, a game relay between chain and the game app to limit fraud, and bots for anti-cheat plus rewards without duplicate grants. Clients hit the same backend from game, web, and bot. Interactive path stayed write-heavy at concurrent ~20, peaking ~100.

Architecture

  • 01Game clientrealtime play
  • 02Web clientaccount · inventory
  • 03Bot clientsanti-cheat · rewards
  • 04Game relaychain ↔ game · anti-fraud
  • 05Cube validateuniqueness in DB · then mint
  • 06Anti-cheat / reward botsno duplicate grants
  • 07Mint pathunique → NFT on-chain
  • 08DB + queuewrite-heavy · Kafka on mint pipeline

What I did

  • Owned game relay — self-built bridge between chain state and the game app
  • Owned cube validation and uniqueness in DB; if unique, mint NFT on-chain (mint path self-built)
  • Owned anti-cheat / reward bots so grants did not duplicate — including airdrop-style reward bots (2 bots · ~500 messages/day · ~2 weeks) in this product context
  • Led a team of ~6 across the write-heavy path (concurrent ~20 · peak ~100) as craftable characters scaled 20³ → 100³; two-cube compare stayed ≤ ~2 minutes start-to-end

Hard problems

User disputes on cube comparison

Symptom
Players contested compare results — claimed the system ranked or matched cubes incorrectly.
Cause
Compare is a start→end measurement over large cube state; any ambiguity in inputs or timing becomes a trust dispute, not just a bug ticket.
Fix
Kept uniqueness and compare authoritative in DB before mint; documented the ≤ ~2 min compare window as the operational bar. No public dispute-rate claimed.

Kafka down mid mint pipeline

Symptom
Mint NFT pipeline stalled when Kafka died mid-flight — cubes validated but NFTs did not land.
Cause
Mint path depended on the queue between uniqueness commit and on-chain mint; broker outage left work neither applied nor safely retryable without care.
Fix
Treated mint as an idempotent pipeline with durable handoff after uniqueness; ops focus on broker recovery so validated cubes could resume mint without double-mint. No public MTTR claimed.

Problem

The product needed craftable-character cube → NFT with uniqueness, a relay that kept game and chain honest, and reward / anti-cheat bots that did not double-pay. All three client surfaces (game, web, bot) shared that backend.

Trade-offs

  • Uniqueness off-chain, then mint — enforce unique in DB first; only then mint NFT on-chain. Faster interactive path, with mint as a follow-on that must stay idempotent.
  • Anti-cheat / reward without duplicates — bots own grant logic so rewards cannot be claimed twice; correctness over “fire and forget” notify.

Outcomes

Craftable characters scaled 20³ → 100³. Comparing two cubes stayed ≤ ~2 minutes (start→end). Concurrent ~20 · peak ~100 on a write-heavy path. Team ~6. Public product naming may differ; finer bridge numbers stay internal.