Problem Statement: Persistent 3D Social World
Problem Statement: Persistent 3D Social World — metaverse interview depth
Problem Statement: Persistent 3D Social World
A metaverse platform is a persistent, shared 3D world where thousands of avatars see and affect each other in real time, plus an economy where what you own is real. Two firehoses define the design and pull in opposite directions: a high-rate, lossy pose/presence stream (where everyone is, 10–30 Hz) and a low-rate, must-be-exact economy stream (who owns what, who paid whom).
The core tension
The whole architecture follows from one split: ephemeral poses are AP (a dropped position update is invisible a frame later) while inventory and wallet are CP (a duplicated sword or a double-spent coin is a scandal). Treating these the same — one consistency model for both — is the mistake that sinks the design. Say the split first.
Interest management is the scaling trick
No client can receive 50,000 avatars' updates. Interest management / area-of-interest (AOI) means a client only receives updates for avatars within its region — so replication cost scales with local density, not total population. A venue caps at ~500 visible avatars; beyond that you shard the space or cull by relevance.
Scale anchors and failure stories
Anchor the numbers — shards of ~100–5,000 concurrent users, pose updates at 10–30 Hz, an AOI radius in meters — then name the real outages: a concert that teleports 50k users into one cell (shard melting), client-side item duplication exploits, and voice chat leaking across unrelated shards. Naming these signals you have run a live world, not just drawn boxes.
Key Highlights
- •persistent shard-based world state
- •avatar embodiment across VR/mobile/desktop
- •interest-managed replication for 500+ avatars per venue
- •UGC economy with server-authoritative inventory
Pose quantization + area-of-interest: the two moves that make presence scale
Poses are AP and high-rate, so compress hard; interest management only replicates avatars within a client's AOI, so cost scales with local density, not total population.
1 def quantize_pose(x: float, y: float, z: float, bits: int = 16) -> tuple[int, int, int]: 2 """Poses are AP and high-rate, so compress hard: 16-bit fixed-point per axis 3 shrinks a pose update to a few bytes before it hits the firehose.""" 4 scale = (1 << bits) - 1 5 return (int(x * scale), int(y * scale), int(z * scale)) 6 7 8 def in_aoi(a, b, radius: float) -> bool: 9 # Interest management: a client only gets updates within its area of interest, 10 # so replication scales with LOCAL density, not the whole world's population. 11 dx, dz = a.x - b.x, a.z - b.z 12 return dx * dx + dz * dz <= radius * radius
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me split this into the AP pose/presence firehose and the CP economy commands — opposite consistency needs."
- "Let me quantify shard pose QPS before picking databases."