Mobile Game Backend Architecture for Greater China, Southeast Asia, Japan and Korea: Servers, Regions and Launch-Day DDoS

A mobile or online game serving Greater China, Southeast Asia, Japan and Korea needs a game backend architecture that keeps account and payment data central but puts real-time battle servers close to players: Hong Kong CN2 GIA for mainland China, Taipei for Taiwan, Tokyo and Seoul for Japan and Korea, and Singapore, Bangkok or Kuala Lumpur for Southeast Asia. IMIDC provides servers in all of these locations, with DDoS protection for launch day and a path from a single VPS to dedicated servers and host nodes.

The reference architecture: five tiers

Split the backend by how much state each tier holds, because stateless tiers scale by adding boxes while stateful tiers need careful placement.

Battle servers should be disposable: if one dies, only the matches on it end. Everything a player owns lives in the data tier.

TCP, WebSocket or UDP with KCP?

Use TCP or WebSocket for turn-based, card and idle games, and UDP with a reliability layer such as KCP for action, shooter and MOBA-style real-time play.

Region placement for Asian players

Place battle servers by where players physically are and how their ISPs route, then verify with real mtr traces from each target network.

One compliance note: hosting in Hong Kong needs no ICP filing, but publishing a game to mainland Chinese players is regulated separately (for example, game publishing approval). Server location does not change that; check with a qualified advisor. This is not legal advice.

Hands-on: tune Linux for UDP battle servers

Default Linux socket buffers are sized for general workloads; bursty game traffic needs larger UDP buffers and backlogs.

# /etc/sysctl.d/90-game-udp.conf  (battle / room servers)
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.core.netdev_max_backlog = 50000
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 10240 65000
fs.file-max = 2097152

# apply and verify
sysctl --system
sysctl net.core.rmem_max
# watch for dropped UDP packets during load tests
netstat -su | grep -Ei "receive buffer errors|packet receive errors"

# open the battle-server port range (ufw example)
ufw allow 7350/tcp
ufw allow 30000:30999/udp

If receive buffer errors keeps climbing during a load test, the kernel is dropping packets before your server reads them: raise the buffers, pin game processes to cores, or run fewer rooms per process. Also enable BBR on TCP gateways and raise ulimit -n for processes holding many sockets.

Hands-on: a Nakama backend in Docker

Open-source servers such as Nakama (accounts, matchmaking, chat, leaderboards) or Colyseus (Node.js rooms) get a studio from prototype to soft launch without writing every service from scratch.

# docker-compose.yml - Nakama game backend + PostgreSQL (single node, staging)
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: nakama
      POSTGRES_PASSWORD: change-me
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 5s
      retries: 10
  nakama:
    image: heroiclabs/nakama:3.22.0
    depends_on:
      postgres:
        condition: service_healthy
    entrypoint:
      - "/bin/sh"
      - "-ecx"
      - >
        /nakama/nakama migrate up --database.address postgres:change-me@postgres:5432/nakama &&
        exec /nakama/nakama --name nakama-hk1
        --database.address postgres:change-me@postgres:5432/nakama
        --session.token_expiry_sec 7200 --logger.level INFO
    ports:
      - "7349:7349"              # gRPC API
      - "7350:7350"              # HTTP / WebSocket API for clients
      - "127.0.0.1:7351:7351"    # admin console: localhost only
    restart: unless-stopped
volumes:
  pgdata:

# start: docker compose up -d && docker compose logs -f nakama

• Clients connect to port 7350; keep the console (7351) on localhost and reach it through an SSH tunnel.
• Replace change-me and set server and session keys before any public test.
• For Colyseus, the equivalent is a Node.js container exposing port 2567 behind Nginx with WebSocket upgrade enabled.
• For production, move PostgreSQL to its own dedicated server with NVMe/SSD and daily off-site backups.

Redis and database tiers

Redis handles anything hot and short-lived; the relational database handles anything a player would complain about losing.

• Redis: session tokens, online presence, matchmaking queues, rate-limit counters and leaderboards (sorted sets). Run a primary with a replica and AOF enabled.
• MySQL/PostgreSQL: accounts, inventory, purchases. One primary in the home region with a read replica; shard by player ID or by game zone (server/realm) once a single primary gets busy.
• Cross-region writes: keep a single source of truth for accounts and purchases. Regional battle servers report results back asynchronously through a queue rather than writing directly across the sea.
• Logs and analytics: ship events to a separate store (ClickHouse, Kafka) so analytics queries never slow down gameplay.

DDoS protection for launch day

Game launches are prime DDoS targets, from competitors, extortionists or angry players, so plan protection before the store page goes live.

• Put login and payment APIs behind CDN and IMIDC DDoS protection; never expose the database or Redis to the internet.
• Do not publish battle-server IPs in DNS. Hand them out only when a match is assigned, together with a short-lived token the battle server validates.
• Drop unauthenticated UDP early: the first packet must carry a valid token, or the process ignores it.
• Keep spare IPs and pre-built server images so you can move an attacked region quickly; IP resources and Anycast with your own ASN help larger studios.
• Tell IMIDC sales your launch date and expected peak traffic in advance so protection and capacity can be planned.

Scaling from VPS to dedicated servers and host nodes

Scale in stages, moving the tier that hurts first, usually the database or battle servers, to bigger hardware.

Concurrency per server varies enormously with tick rate and game logic, so treat these numbers as planning ranges and load-test with bots before each stage.

Which IMIDC setup fits

Match the product to the tier and the market rather than buying one size everywhere.

• Mainland China players: Hong Kong CN2 GIA VPS for gateways and small battle pools, Hong Kong dedicated servers for heavy battle and database tiers.
• Taiwan players: Taiwan VPS or Taiwan dedicated servers.
• Japan and Korea: Japan VPS, Japan dedicated, Korea VPS and Korea dedicated on the KT network.
• Southeast Asia: Singapore, Bangkok and Kuala Lumpur servers configured via sales.
• Moving from another cloud: free server migration, plus custom builds (high-clock CPUs, extra RAM, private networking) through sales.

FAQ

Where should I host a mobile game that serves both mainland China and Southeast Asian players?

A common split is battle servers on IMIDC Hong Kong CN2 GIA for mainland players and Singapore or Bangkok servers for Southeast Asia, with one shared account and payment backend. Hong Kong alone can also serve parts of Southeast Asia acceptably, but test with real players before deciding.

Should my game server use TCP or UDP?

Turn-based, card and idle games are fine on TCP or WebSocket. Real-time action, shooters and MOBAs benefit from UDP with a reliability layer such as KCP, plus a TCP fallback for networks that block UDP.

Do I need ICP filing to host a game server in Hong Kong for Chinese players?

No ICP filing is needed for servers hosted outside mainland China, including IMIDC Hong Kong. Game publishing in mainland China is regulated separately, so check with a qualified advisor; this is not legal advice.

Which provider has game servers in Seoul on the KT network and in Tokyo?

IMIDC offers VPS and dedicated servers in Seoul on the KT network and in Tokyo, both with local native IPs, alongside Hong Kong, Taipei and Southeast Asian locations.

How do I protect a game launch from DDoS attacks?

Combine provider-level DDoS protection with architecture: hide battle-server IPs until a match starts, require tokens on the first UDP packet, and keep login APIs behind CDN. Tell IMIDC your launch date in advance so capacity and protection can be planned.

Ready to plan your Asia launch? Start with a Hong Kong CN2 GIA VPS or Seoul dedicated server, contact IMIDC sales for Singapore, Bangkok and Kuala Lumpur nodes or a launch-day DDoS plan, or open a ticket to talk through your architecture with an engineer.