# Design a Real-Time Multiplayer Mobile Game: Pokemon Go-Style

Source: https://www.techinterview.org/post/3233475044/design-realtime-multiplayer-mobile-game/
Updated: 2026-07-26 · techinterview.org

Designing a real-time multiplayer mobile game touches more disciplines than almost any other mobile [system design](/system-design-interview-guides/) question — location services, real-time networking, AR, anti-cheat, server architecture, battery, and the operational realities of a game with millions of concurrent players.

## Functional requirements

- Real-time location-based gameplay — the map updates as the player physically walks. Interviewers probe how often you sample GPS and how you turn raw coordinates into a spatial index so the server can cheaply answer "what is near this player right now."

- Encounter creatures/items in the world — spawns appear at real-world locations and the player taps to engage. Be ready to say who owns the spawn table (the server) and how many nearby spawns you stream to the client at once so you don't flood the map.

- Battle other players or NPCs — combat between two players, or a player against a computer opponent. The part interviewers push on is keeping both clients in sync when their network latency differs, which is where prediction and correction come in.

- Chat / friends — add friends, send messages, trade items. Expect a follow-up on why the messaging subsystem is built and scaled separately from the game loop instead of riding the same session servers.

- Persistence — inventory, levels, achievements. Everything caught and every level gained must survive app restarts and a switch to a new device, so interviewers ask what data is authoritative on the server versus merely cached on the phone.

- AR experience (camera-overlay rendering) — rendering the creature over the live camera feed. Know when to argue AR is core versus optional, since it is the heaviest battery and compute cost in the whole app.

## Non-functional

- Sub-200ms input-to-screen for actions

- Battery: 1 hour of gameplay should drain ~15-25%

- Resilient to network drops

- Anti-cheat — server-authoritative for important actions

## Architecture

Three main systems: **client**, **game session**, **persistence**.

## Server-authoritative actions

Anything that affects gameplay state must be server-authoritative. Catching a Pokemon, completing a battle, leveling up — the server decides. The client requests, the server validates and confirms.

Why: cheaters can modify the client. If the client reports "I caught 100 legendaries," the server should reject this without server-side validation.

## Real-time location

Sample GPS every 1–3 seconds during gameplay. Push to server. Server maintains the player's session state and broadcasts visible game events to the player based on their geolocation (s2 cell-based partitioning).

## Spawn logic

Server determines what creatures spawn where, when, and to whom. Client receives a list of nearby spawns; renders them on the map. Spawn data is server-authoritative — clients cannot wish creatures into existence.

## Battle protocol

For real-time battles between players:

- Both clients connect to the same game session server

- Inputs sent to server with sequence numbers and timestamps

- Server simulates the battle deterministically

- Outcomes broadcast back to both clients

- Clients render with prediction + correction (rollback netcode for fairness)

## AR rendering

iOS: ARKit places the creature in the camera feed using world tracking. Android: ARCore equivalent.

For lower-end devices, fall back to a 2D overlay over the camera feed without full 3D world tracking.

## Anti-cheat

- Server-authoritative everything important

- Detect impossible movement (teleporting, flying speeds)

- Detect spoofed locations (mock GPS detection on Android, jailbreak detection on iOS)

- Behavioral analytics on the backend (catch rates, walking speeds, distance traveled)

- Shadow ban or warn for first offenses; full ban for repeated

## Battery

- GPS at moderate accuracy when stationary; high accuracy only when moving

- Camera for AR is the biggest battery hog — disable when not actively encountering

- Disconnect from session server when game minimized for >30 seconds

## Persistence

Player state in a [sharded database](/post/3233459955/database-sharding/) (DynamoDB, Spanner, or sharded MySQL). Inventory, achievements, friends. Hot-state cached in Redis for low-latency reads during gameplay.

## Frequently Asked Questions

### How do you handle a player who loses connection mid-battle?

Pause the battle for ~30 seconds awaiting reconnect. If reconnect fails, AI takes over the player's side or the battle is forfeit (depending on game design). Server logs are authoritative.

### Why is Pokemon Go server load spiky?

Special events (Community Day) concentrate millions of players in narrow time windows. Capacity must be 10–20x baseline, and the architecture must shard across regions to handle it.

### How do you detect GPS spoofing?

Inconsistent location/sensor readings (GPS says you are walking but accelerometer says you are stationary), impossible velocities, or location-modification API detection.